解读

面试官真正想考察的并不是“看版本号”本身，而是你对 grunt-cli 与 grunt 本地包之间“桥梁”机制的理解深度。
在国内前端工程化面试中，“全局 grunt-cli + 本地 grunt” 是 90% 团队仍在沿用的模式，但候选人往往只能答出 grunt --version，却解释不清“为什么全局 1.5.3 却跑出了 1.0.4”这类现场排障场景。
因此，回答必须体现三点：

1. 能精准定位 cli 实际加载的本地 grunt 路径；
2. 能复现版本号并给出可脚本化的验证方案；
3. 能预判多项目、tnpm/cnpm 私有源、monorepo 等国内常见“坑”。

知识点

• grunt-cli 只是一个全局转发器，其逻辑写在 ~/.config/yarn/global/node_modules/grunt-cli/bin/grunt（或 npm 全局目录），核心代码 resolve("grunt", { basedir: process.cwd() }) 会按 Node 模块解析规则向上递归查找最近 node_modules 里的 grunt 包。
• 因此**“grunt --version” 打印的两个版本号中，第二行才是本地实际被加载的 grunt**；第一行只是 cli 自身版本，常被误读。
• 若项目使用pnpm/tnpm 虚拟存储或Yarn PnP，模块路径可能不在 node_modules/grunt，需用 node -p "require.resolve('grunt/package.json')" 拿到真实物理路径。
• 在CI/私有仓库场景，国内镜像源同步延迟会导致 package.json 与 npm ls grunt 不一致，必须以磁盘实际 package.json 的 version 字段为准。
• 若团队使用husky + lint-staged做前置检查，可把版本校验脚本 node -e "console.log(require('grunt/package.json').version)" 写进 pre-grunt 钩子，防止“本地跑得过、线上 grunt 降级失败”事故。

答案

1. 先确认 grunt-cli 已全局安装：
   npm ls grunt-cli -g 或 yarn global list | grep grunt-cli
2. 进入项目根目录，执行：
   grunt --version
   输出示例：
   grunt-cli v1.5.3
grunt v1.0.4
   第二行即为本地被加载的 grunt 版本。
3. 脚本化验证（兼容 pnpm/cnpm）：
   node -p "require(require.resolve('grunt/package.json')).version"
   该命令直接打印本地 grunt 版本号，不受全局 cli 版本干扰，可在 Jenkins、GitHub Actions 等国内云托管平台稳定复现。
4. 若出现“grunt-cli 找不到本地 grunt”报错，说明目录下未安装 grunt，需先 npm i grunt -D 再验证。

拓展思考

• 在大型 monorepo 里，子包可能共用根节点 grunt，也可能各自锁定不同版本。可写一条 lerna exec 命令批量执行上述脚本，一分钟内扫出所有子包真实 grunt 版本，避免“根目录升级 grunt 后某个遗留子包仍然调用旧版”导致的构建结果差异。
• 若团队准备迁移到 grunt 1.5+（开始要求 Node ≥ 14），可先把验证脚本加入 Dockerfile：
  RUN node -e "process.exit(require('grunt/package.json').version.startsWith('1.5')?0:1)"
  镜像构建失败即说明基础镜像未升级，提前拦截上线风险。
• 对于**“双引擎”项目**（老模块用 grunt，新模块用 webpack），建议在 package.json 的 engines 字段里显式声明 grunt 版本区间，并配合 check-grunt-version.js 脚本在 preinstall 阶段校验，防止新同学误装 grunt 0.4 导致插件不兼容。