sourcemap 能追溯到最初代码靠的是“映射链”，即ts→js→压缩→打包每步生成并保留上一级.map文件，由babel、terser、webpack等工具逐级读取合并，最终在浏览器中透明回溯至源码。
SourceMap 能追溯到最初代码，靠的不是单层映射，而是“映射链”（source map chain）——每一步转译只要生成并保留上一级的 SourceMap，最终就能逐级回溯。关键不在“完美”，而在“链路完整”和“工具兼容”。
映射链如何形成
现代前端构建中，代码通常经历：TS → JS（Babel）→ 压缩混淆（Terser）→ 合并打包（Webpack/Vite）。每步若开启 sourcemap 输出，就会产生一个 .map 文件，并在产物末尾写入 //# sourceMappingURL=xxx.map 指向它。更重要的是：后一步工具能读取前一步输出的 .map，将其“嵌入”或“链接”进自己的新 .map 中。
- TS 编译器（tsc）生成
index.ts → index.js + index.js.map - Babel 接收
index.js，同时读取其index.js.map（需配置inputSourceMap: true），输出index.es5.js + index.es5.js.map，其中mappings已包含从index.es5.js→index.js→index.ts的两级跳转 - Terser 压缩时，若传入
--source-map-include-sources或启用sourceMap: { includeSources: true }，会把上一级的sourcesContent（即原始 TS 内容）也带进来；同时它的mappings字段会把压缩后位置映射到 Babel 输出的 JS 行列，而该 JS 的 map 又指向 TS —— 链就闭合了
必须满足的三个前提
缺一不可，否则链断裂，只能回溯到某一层：
-
每步都开启 sourcemap 生成：TS 的
"sourceMap": true、Babel 的sourceMaps: true、Terser 的sourceMap: true、Webpack 的devtool: 'source-map'（非eval类） -
中间产物 .map 文件不能丢失：Webpack 默认把所有 .map 打包进 dist，但若配置了
devtool: 'hidden-source-map'或手动清理了 .map，浏览器就无法加载中间链 -
工具支持 source map 链式消费：Babel 7+、Terser 4.6+、Webpack 5+、Vite 3+ 均原生支持读取输入文件附带的 sourceMappingURL 并合并映射；旧版本需手动传参或插件（如
babel-plugin-source-map-support）
浏览器里实际怎么回溯
当你在 Chrome DevTools 中看到报错堆栈显示 index.ts:12:5，背后发生的是：
- 浏览器加载压缩后的
bundle.min.js - 解析末尾注释，下载
bundle.min.js.map - 读取该 map 的
mappings，发现第 X 行第 Y 列对应的是index.es5.js第 A 行第 B 列 - 再根据
bundle.min.js.map中的sources和sourcesContent（若内联），或自动请求index.es5.js.map（若外链），继续解码 - 最终定位到
sourcesContent[0]即原始 TS 字符串的第 12 行
整个过程对开发者透明，前提是链上每个 .map 都可访问且格式合规。
常见断链场景与修复建议
-
生产环境禁用 map 但又想查线上问题：改用
devtool: 'hidden-source-map'，不暴露 sourceMappingURL 注释，但保留 .map 文件上传至错误监控平台（如 Sentry），由平台服务端完成映射解析 -
第三方库没提供 map：Webpack 的
devtoolModuleFilenameTemplate可强制重写源路径；或使用source-map-loader尝试提取已内联的 map -
TS + Babel 双重转译导致重复 map：关闭 TS 的
declarationMap（仅用于类型检查），Babel 配置inputSourceMap: true并设sourceMaps: 'inline'避免多层外链
