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

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

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

2013 年前端开发已经越来越离不开浏览器开发者工具了。页面一出问题，如果不会用 DevTools，很多排查只能靠猜。

样式问题最容易让人陷入一种低效循环：改一处 CSS，刷新页面，看不对，再回去改下一处。尤其是接手别人留下来的页面时，选择器层级多、覆盖关系杂，如果只在源码里猜，很快就会迷路。

浏览器里出现白屏、按钮没反应、数据不显示时，很多人的第一反应还是回编辑器里盯代码。但真到项目节奏快的时候，这种做法经常会让人越看越散。Chrome DevTools 真正有用的地方，是它能先帮你把问题范围收住。

刚开始做响应式时，很多人会先去搜“iPhone 多宽、iPad 多宽、常见安卓机多宽”，然后把这些数字直接写进媒体查询。这样当然能快速起步，但做几个页面之后就会发现，只按设备型号设断点，维护起来很容易僵。

到了 2013 年，很多网站已经不能再只盯着桌面浏览器了。手机和平板访问越来越多，页面如果还是固定宽度、固定结构，用户体验会立刻掉下来。

响应式设计讲起来可以很大，但真落到一个老页面改造时，最先让人头疼的常常不是整套布局，而是几个特别显眼的元素：一张固定宽度的大图，或者一排在桌面端很自然、到手机上立刻挤爆的导航。

响应式设计刚开始被大量讨论时，很多教程都会先让你加上一行 viewport。代码看起来很简单，但如果只会照抄，不理解它在手机浏览器里到底改变了什么，后面布局一出问题还是容易手忙脚乱。