把 JSHint、watch 和 LiveReload 串起来才像真正的日常流程

很多人第一次给 Grunt 配任务，会优先想到压缩和拼接，因为这些动作看起来最像“构建”。但如果从每天写代码的体验来看，更能拉开效率差距的其实是另一组能力：保存文件后自动检查、自动重跑任务、自动刷新页面。

监听不是为了炫技，而是为了减少切换成本

前端开发最烦的不是改代码本身，而是不断重复“保存文件、切回浏览器、手动刷新、再看结果”。这个动作一旦一天发生几十次，人的注意力会被切得很碎。

Grunt 的 watch 在当时最有价值的地方，就是把这些重复动作收了起来。改了脚本，就跑脚本相关检查；改了样式，就刷新页面；改了模板，就触发对应任务。只要监听范围划得合理，开发节奏会顺很多。

JSHint 放在前面，比出错后再找更省力

2013 年很多项目还没有后面那么成熟的编辑器提示，变量拼错、少写逗号、漏掉分号，经常要等页面报错才发现。把 JSHint 接在 watch 前面，相当于在保存时就先挡掉一批低级问题。

这不是为了追求代码洁癖，而是为了减少“页面怎么突然不动了”的排查时间。尤其是多人协作时，统一的检查规则能避免很多风格和语法层面的来回沟通。

LiveReload 要小心别把生成目录也一起盯上

LiveReload 确实方便，但早期配置常见一个坑：源码目录和输出目录都在监听范围里。结果一个文件变化会触发打包，打包又改了输出文件，输出文件再触发刷新，最后任务像循环一样停不下来。

所以监听规则宁可细一点，也别图省事把整个项目全交给 watch。只盯源码目录，明确哪些变化需要重新构建，哪些只需要刷新，流程才会稳定。

小结

Grunt 真正进入“日常可用”状态，不是在你装了多少插件之后，而是在 JSHint、watch、LiveReload 这些细节接顺之后。它们解决的不是发布时的体面，而是开发时最频繁、最琐碎、也最消耗注意力的那部分劳动。