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

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

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

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

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

2014 年前端最明显的变化之一，就是大家开始不再满足于“jQuery 把页面拼起来”这种方式了。页面逻辑越来越复杂，数据与视图之间的关系也越来越需要一种更系统的组织方法。

刚接触 AngularJS 时，如果只看到模板语法和双向绑定，很容易把它理解成“更会操作页面的 jQuery”。但真正让项目组织方式发生变化的，往往是 service 和依赖注入这套东西。它让数据请求和公共逻辑开始有了固定归宿。

第一次看 AngularJS 的指令示例时，很容易觉得它像一种“什么都能包起来”的能力。按钮、列表、弹层、表单，似乎都可以做成指令。这个想法没错，但如果刚入门就把所有逻辑都往指令里塞，通常很快会把自己绕进去。

列表页做缓存，最先想到的写法通常很直接：第一页缓存成一个 key，第二页再来一个 key。
刚开始看完全没问题，可 2014 年我在给后台列表和内容列表做 Redis 缓存时，很快就遇到现实难题：真正决定一页内容的，根本不只是页码。

2014 年前后，Node.js 配 Redis 是很常见的一套轻量组合。大家一开始都觉得 Redis 上手快，set、get 会用就能干活，但真把它放进登录态、验证码、计数器、页面缓存之后，问题很快就来了：key 越堆越多，过期时间各写各的，最后自己都看不懂线上到底存了什么。