解读

在国内前端团队里，Grunt 仍被大量老旧项目与内部脚手架沿用。面试官问“加载差异”，并不是让你背源码，而是考察三点：

1. 是否知道 Grunt 如何定位并解析配置文件；
2. 是否理解 Node 原生对 .js 与 .coffee 的加载机制差异；
3. 能否把差异映射到真实工程问题（依赖安装、性能、跨平台、CI）。
   答得太浅（“一个用 JS 一个用 Coffee”）会被直接打断；答得太偏（“Coffee 编译成 AST 再……”）会被认为过度炫技。必须给出可落地的差异点与踩坑经验。

知识点

1. 文件定位顺序：Grunt CLI 先按 grunt.file.searchBases 数组依次查找 Gruntfile.js、Gruntfile.coffee、Gruntfile.ts 等，命中即停。
2. Node 原生加载：
   • .js 走 require() 默认的 CommonJS 路径，同步编译、缓存到内存，无需额外依赖。
   • .coffee 必须先注册 require.extensions['.coffee']；若本地未装 coffeescript 包，Node 会抛 Cannot find module 'coffeescript'。
3. Grunt 的兜底策略：当加载 .coffee 时，Grunt 会在当前项目 node_modules 与全局 node_modules 双路径下尝试解析 coffeescript，解析失败才报错；而 .js 无此兜底。
4. 性能差异：.coffee 文件在首次 require 时由 CoffeeScript.register() 实时转译，每进程一次，后续命中缓存；对单次 CLI 调用几乎无感，但在多进程并发构建（如 Jenkins 并行矩阵）中，每次新建进程都要重复转译，冷启动慢 100～200 ms，累积可观。
5. 跨平台隐坑：Windows 上若全局安装 grunt-cli 却未在项目本地装 coffeescript，会触发全局本地双路径查找失败，报错信息被 Grunt 包装成“Gruntfile 未找到”，新人极易误判为路径大小写问题。
6. SourceMap 与调试：.coffee 生成的堆栈行号与列号经 coffeescript 二次映射，若同时启用 grunt-contrib-uglify 的 sourceMap，需把 sourceMapIn 指向 .coffee 的 .map，否则 Sentry 上报无法还原原始行列，排查难度翻倍。

答案

“Gruntfile.js 与 Gruntfile.coffee 的加载差异主要体现在文件定位、依赖注入、运行时转译与跨平台容错四个层面。
首先，Grunt CLI 按固定顺序搜索配置文件，一旦找到 .js 就立即 require，而 .coffee 需要本地或全局存在 coffeescript 包，由 Grunt 在加载前隐式执行 require('coffeescript/register')，否则抛模块未找到异常。
其次，.js 直接走 Node 原生 CommonJS 缓存，零额外成本；.coffee 则在首次加载时由 CoffeeScript 实时编译成 JS 再交付 Node，虽然单次耗时仅百毫秒，但在 CI 矩阵或 Docker 冷启动场景下，每次新建容器都会重复转译，拉长了流水线总时长。
第三，Windows 环境若只全局装 grunt-cli 却未在项目本地装 coffeescript，.coffee 会触发双路径解析失败，报错信息被包装成找不到 Gruntfile，容易误导排查方向；而 .js 不存在这类隐式依赖。
最后，若项目需输出 SourceMap 做线上错误还原，.coffee 需要额外把 sourceMapIn 指回 .coffee 的 .map 文件，否则 Sentry 等监控平台只能定位到转译后的 JS 行列，排查效率大幅下降。
综上，新工程建议优先使用 .js 降低环境耦合；遗留 .coffee 必须在 package.json 显式声明 coffeescript 依赖，并在 CI 镜像里预装，才能避免跨平台与性能隐患。”

拓展思考

1. 混合配置策略：把耗时任务（如图片压缩）用 .js 编写，把易读配置（如自定义 task 列表）用 .coffee 维护，通过 module.exports = require('./Gruntfile.coffee') 在 Gruntfile.js 里转发，既保留 Coffee 的简洁，又避免冷启动损失。
2. TS 化迁移：如果团队已全面拥抱 TypeScript，可先用 ts-node/register 替代 coffeescript/register，把 Gruntfile.ts 纳入类型检查，再逐步把遗留 .coffee 任务重写成 .ts，一次性解决 Coffee 依赖与类型安全两个问题。
3. CI 缓存优化：在 GitHub Actions 或 GitLab CI 中，把 node_modules/.cache/coffeescript 加入缓存 key，避免每次重新转译；实测可将 .coffee 冷启动从 180 ms 降到 30 ms，基本抹平与 .js 的差距。