2016 年接手 Java 项目时，我遇到过一种很典型的混乱：同样是处理用户逻辑的类，有的叫 UserDao，有的叫 UserMapper，有的叫 UserServiceImpl，还有的直接叫 UserManager。项目还能跑，但只要需求稍微一变，大家就会先花时间猜“这个类到底管什么”。

图片上传这类接口最容易在需求讨论里被说成一句话：选文件，传上去，返回地址。
可 2016 年我在做这类功能时越来越明显地感觉到，一个上传接口如果一开始只关注“体验顺不顺”，却没有先限制大小、类型和错误边界，后面出问题会非常频繁。

带坐标的数据一多，最常见的需求之一就是“按距离最近排序”。
很多人一开始会先把经纬度查出来，再在应用层自己算距离、自己排序。小数据量时确实能跑，但 2016 年我在看这类场景时越来越觉得，所有距离计算都堆在应用层，其实是在主动放弃数据库已经能帮你做的一部分工作。

服务启动失败这件事，最怕的不是问题复杂，而是人一慌就到处乱看。2016 年自己管机器的时候，我也吃过这种亏：一发现接口没起来，就先怀疑代码、怀疑框架、怀疑依赖版本，结果折腾了半天，最后只是端口被别的旧进程占着。

给老 PHP 项目加缓存，表面上看很像一件“性能补丁”工作：慢了就加缓存，数据库忙了就挡一层。
可 2016 年我自己在碰这类改造时，最大的感受不是技术难，而是很多老项目根本没人能完整说清楚数据到底是怎么读出来、又是从哪里被改掉的。

2016 年做接口优化时，缓存几乎是最容易被提起的方案。接口慢了，加缓存；数据库忙了，加缓存；列表页扛不住了，还是加缓存。可真正做过几轮之后，我反而越来越谨慎，因为缓存很少是“开了就完事”的提速按钮。

很多人一说文章迁移，会先想到正文是不是完整、标题和日期有没有带过去。
这些当然重要，但 2016 年我在整理和迁移一批 Markdown 内容时，最让我头疼的反而不是纯文本，而是那些看起来像细节、丢了却很影响阅读体验的东西。

2016 年还在自己管服务器的时候，我最怕的不是部署命令难写，而是 SSH 连上去之后，所有动作都挤在一个窗口里：看日志在这里，改配置在这里，重启服务也在这里。只要网络抖一下，或者手快切错目录，整个节奏就乱了。

服务器刚开出来的时候，最诱人的动作通常是立刻登录上去装环境、拉代码、跑服务。
我早期也经常这样做，因为会觉得业务先上线最重要。可 2016 年之后自己管机器越来越多，我反而越来越愿意先停几分钟，把基础加固做完再继续。

MongoDB 副本集这套能力刚接触时，很容易给人一种“数据已经更安全了”的感觉。这个判断不算错，但如果进一步把它理解成“那就等于已经做好备份了”，问题就会变得很严重。2014 年我在看一些 MongoDB 部署经验时，越来越觉得这两个概念必须尽早分开。