解读

面试官抛出这道题，并不是想听你背概念，而是想确认三点：

1. 你是否真的在本地机器和 CI 环境里亲手装过 grunt-cli，还是只会 npm install；
2. 你是否理解“全局命令”与“项目依赖”分离的设计意图，这关系到多项目 grunt 版本共存的痛点；
3. 当构建报错 “Local Npm module ‘grunt’ not found” 时，你能否秒定位是缺失了 grunt 包还是 grunt-cli 版本过旧。
   一句话，这道题考察的是**“构建环境拆解与故障排查”**的硬实力，属于国内一线厂前端基建面试的高频“坑”。

知识点

1. grunt-cli（全局）
   职责：暴露 grunt 命令到系统 PATH；不携带任何任务逻辑，仅完成“版本调度”与“子进程启动”。
   安装：npm i -g grunt-cli@版本号，国内镜像源建议配淘宝源或公司私服，否则 CI 拉包会超时。

2. grunt（本地）
   职责：项目真正的构建引擎，读取 Gruntfile.js，加载插件，注册任务队列并执行；版本锁定在 package.json 的 devDependencies，保证团队&线上构建可复现。

3. 加载顺序（面试必须按序背出）
   ① 用户在终端键入 grunt → 系统 PATH 找到全局 grunt-cli；
   ② grunt-cli 立即 process.cwd() 定位到项目根，查找 node_modules/.bin/grunt；
   ③ 若本地 grunt 不存在，cli 直接抛错 “A local grunt could not be found”，不会回退到全局，这是刻意设计；
   ④ 若存在，cli 通过 require("module")._nodeModulesPaths 解析出本地 grunt 入口，再起一个子进程 node grunt.js 把控制权和参数完整移交；
   ⑤ 本地 grunt 启动后，按 Gruntfile 中 task 顺序执行，生命周期钩子依次为：init → loadNpmTasks → registerTask → run。

4. 国内踩坑点

   • 公司内网 CI 镜像缓存旧版 grunt-cli，本地高版本 grunt 与 cli 1.2.0 以下不兼容，导致任务静默失败；
   • Windows 机器同时装过 grunt-cli 0.1.x 与 1.x，PATH 顺序决定哪个先命中，需 where grunt 排查；
   • 多人协作时把 grunt 误写进 dependencies 而非 devDependencies，线上容器装包体积暴增 40 MB，面试可提一嘴优化方案。

答案

grunt-cli 是全局命令行工具，只负责找到并调用项目本地的 grunt，自身不含构建逻辑；grunt 包是项目级依赖，真正解析 Gruntfile、调度插件、运行任务。加载顺序是：终端输入 grunt → 全局 grunt-cli 启动 → cli 检索本地 node_modules 里的 grunt → 若存在则 spawn 子进程移交控制权 → 本地 grunt 接管并按任务队列执行。若本地 grunt 缺失，cli 立即报错退出，不会回退到全局，从而保证多项目版本隔离。

拓展思考

1. monorepo 场景：lerna 或 pnpm workspace 把 grunt 安装在根目录，子包没有独立 node_modules，此时 grunt-cli 如何解析？
   答：cli 会沿 process.cwd() 向上递归查找 node_modules，找到根目录的 grunt 即视为“本地”，因此需在根目录执行 grunt，子包内执行会找不到。

2. 性能优化：大型项目 Gruntfile 动辄 400+ 任务，本地 grunt 启动一次需 3 s，可通过 grunt --gruntfile .grunt/mini.js 拆分出“开发/生产”两份配置，把 60% 插件懒加载，启动时间降到 800 ms 以内，面试提到此方案可加分。