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

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

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

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

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

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

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

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

2014 年做内容站和后台系统时，MongoDB 很吸引人，原因很简单：模型灵活、起步轻、开发速度快。可一旦列表页慢下来，很多团队的第一反应都是“是不是该上副本集”“是不是该多加几台机器”。我后来发现，这种反应往往太快了。

AngularJS 真正用到多页面切换时，很多新问题会一起冒出来。为什么切个路由控制器就重新执行了？为什么某个值明明变了，页面却没有马上更新？为什么 watch 一多以后页面开始变慢？这些问题如果分开看，很容易越学越乱。