解读

面试官真正想考察的是：

1. 你是否理解 source-map 的本质——把压缩后的代码位置映射回原始源码；
2. 你是否知道 合并 source-map 在持续集成、灰度发布、线上故障排查中的落地价值；
3. 你是否能结合 Grunt 生态给出 可复现、可回滚、可审计 的工程化方案。
   一句话，“能在线上 5 分钟内把报错栈还原到 Git 原始行号” 才是得分点。

知识点

1. source-map 合并（concat + uglify + source-map）：
   多文件先 concat 再 uglify 时，必须逐级把每一步的映射关系串起来，否则最终 map 只能指向合并后的中间文件，无法定位到业务源码。
2. Grunt 链式插件顺序：
   grunt-contrib-concat → grunt-contrib-uglify（需开启 sourceMapIn/sourceMap 选项）→ grunt-sourcemap-merge，保证“一张总图”贯穿到底。
3. 国内网络与合规要求：
   线上服务器禁止暴露 .map 文件，需通过 内网溯源平台 或 Sentry 私有部署 做符号表上传，实现“外网无 map，内网可还原”。
4. 调试闭环：
   用户端产生错误 → 日志平台收集堆栈 → 符号表服务解析 → 直接跳转 GitLab 行号 → 钉钉群机器人 30 秒内推送源码位置、commit、作者。

答案

“source-map 合并的意义，是把多阶段构建产生的映射关系逐级串联，最终生成一张**‘从线上单行压缩代码 → 原始业务源码’的完整导航图**。
在 Grunt 流水线里，我会先让 concat 生成 bundle.js.map，再让 uglify 以 sourceMapIn 读取它，最后通过 grunt-sourcemap-merge 把第三方库（如 vendor）的 map 也合并进来，产出 app.min.js.map。
这张总图不会随文件发到 CDN，而是在发布脚本里自动上传到内网符号表服务。
一旦线上出现 Cannot read property 'xxx' of undefined，Sentry 在 200ms 内就能把堆栈还原成 src/pages/order/list.vue:137，并带上 Git commit a1b2c3d 和作者张三。
这样免去了本地拉取对应版本、手动反编译、定位行号的 30 分钟浪费，真正把线上故障平均修复时间从小时级降到分钟级，也满足了国内**审计合规‘可溯源、可回滚’**的硬性要求。”

拓展思考

1. 增量合并：
   对于 10 万行以上巨石应用，全量合并 map 耗时 8 秒，可改用 webpack-sources 的 CachedSource 思路，在 Grunt 里做增量缓存，只重编变更模块，CI 时间缩短 60%。
2. 双向映射：
   除了“报错→源码”，还可以把性能打点（如 performance.mark）映射回源码，实现“某条性能曲线突刺”直接关联到 Vue 组件的 mounted 钩子，辅助做线上性能回归。
3. 灰度染色：
   在 map 中注入构建号 + 灰度 ID，当灰度 5% 用户报错时，可快速判断是构建差异还是代码逻辑问题，避免全量回滚带来的业务损失。