Gruntfile 刚搭起来时，任务入口不要一开始就写乱

刚接触 Grunt 时，很容易因为插件多、示例多，直接把 concat、uglify、watch、cssmin 全塞进一个 default 任务里。命令虽然能跑，但过不了几天就会发现：自己已经分不清到底哪个任务给开发环境用，哪个任务给上线打包用。

先把“开发态”和“发布态”拆开

我现在更愿意先把任务按使用场景拆清楚，而不是按插件名字去组织。开发阶段最常用的是监听、语法检查、临时拼接；发布阶段才需要压缩、版本化、拷贝静态资源。

如果一开始不分场景，后面每次改一个小样式也要走一遍完整压缩流程，速度慢不说，还容易把真正有价值的反馈埋掉。对团队成员来说，grunt dev 和 grunt build 这种意图明确的入口，也比一堆插件名更容易记。

任务名字要表达目的，不要只表达动作

很多人早期写 Gruntfile 时喜欢直接暴露 grunt concat、grunt uglify 这样的命令，但协作一多就会发现，动作名说明不了整体流程。真正重要的是“我要启动本地开发环境”还是“我要生成可发布目录”。

所以我会更倾向于给入口任务起这类名字：

• dev 负责本地开发
• check 负责语法和样式检查
• build 负责生成上线资源

这样即便以后把 jshint 换成别的检查工具，命令含义也不会跟着一起漂移。

路径配置最好集中写，不要散在每个任务里

另一个早期很容易忽略的问题，是输入输出路径到处重复。今天改了 src/js，明天忘了改 watch 或 uglify，最后就是某个任务一直盯着旧目录。

更稳妥的做法，是先在配置顶部把几个关键目录定下来，比如源码目录、临时目录、发布目录。Grunt 真正帮到人的地方，不只是自动化，而是让这些重复规则有一个统一归宿。

小结

2013 年前端工程化刚起步时，Grunt 最容易带来的误区不是“不够强”，而是“什么都能做，所以什么都往里堆”。Gruntfile 早期越能把任务入口和场景边界讲清楚，后面新增插件、拆流程、交给别人维护时就越不容易乱。