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

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

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

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

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

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

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

Grunt watch 刚接进项目时，体验真的很好。改一个文件，自动检查、自动编译、自动刷新，前端开发节奏会立刻顺起来。但 2013 年我在几个页面项目里把它用深之后，也很快遇到另一个问题：watch 一旦开始什么都监听、什么都触发，最后开发环境会变得越来越重。

同一台电脑上同时管理多个 SSH key，最开始最容易掉进“我记得这个仓库该用哪个 key”的状态。2013 年我在不同 Git 仓库、不同服务器之间切换时，也常常靠记忆硬撑，结果不是连错主机，就是推送时身份不对。

页面一旦出现“点击没反应”或者“滚动明显发卡”，很多人会笼统地说这是性能问题。但性能问题如果只停在这个词上，其实没有任何帮助。对前端来说，更实用的还是先把问题拆开：是逻辑没走到，还是逻辑走到了但执行得太重。