Source Map 是构建时生成的不可替代的 JSON 映射文件，记录压缩代码与原始源码的行列、文件、标识符对应关系；核心字段包括 sources、mappings、names 和 sourceRoot。
不能靠堆栈自己“猜”行号，必须用构建时生成的 Source Map 文件做映射还原。没有它，混淆后的 a.b.c() 和 123 行就永远对不上原始代码。
Source Map 是什么，为什么它不可替代
它是一个 JSON 文件，记录了压缩后代码每一处位置（行、列）对应原始源码的哪个文件、哪一行、哪一个变量或函数名。核心字段包括：
• sources：原始文件路径列表，如 ["src/App.tsx", "src/utils/api.ts"]
• mappings：Base64 VLQ 编码的映射表，是定位还原的底层依据
• names：原始标识符名（如 fetchUser、handleClick），用于还原函数名
• sourceRoot（可选）：帮助解析相对路径的根目录
关键点：这个映射关系在构建时一次性生成，运行时无法推导。Terser、Webpack、Vite 等工具默认开启，但需确认未被禁用或清理。
还原报错行号的两个主要路径
• 浏览器自动解析（开发调试友好）
– 前提：.js 文件末尾有 //# sourceMappingURL=xxx.js.map 注释
– .map 文件需与 .js 同域、可公开访问（HTTPS、无 CORS 拦截）
– Chrome DevTools → Sources 面板能看到原始文件结构，点击错误堆栈即可跳转
• 服务端/工具手动解析（监控系统必备）
– 错误上报时携带：错误消息、script URL、lineno、colno、完整 stack 字符串
– 后端根据 script URL 找到对应版本的 .map 文件（注意版本匹配！）
– 使用 source-map 或 source-map-js 库调用 originalPositionFor({ line, column })
– 返回结果含 source（原始文件）、line、column、name（函数名）
常见失败原因和检查清单
• 构建产物里没生成 .map 文件 —— 检查构建配置中 devtool（Webpack）或 build.sourcemap（Vite）是否设为 true 或 "hidden"
• .map 文件未部署或路径不对 —— 确保上线时一同发布，且 sourceMappingURL 路径能被浏览器或服务端正确请求到
• 多版本混用 —— 小程序、H5、App 各自版本的 .map 必须严格对应出错时的 JS 版本，否则映射错乱
• 源码已修改但未重新构建 —— .map 只忠实反映构建那一刻的源码结构，改了代码却不重打包，还原必错
• Android/iOS 原生容器拦截资源 —— 移动端需确认 WebView 允许加载外链 .map，iOS 还需校验 .dSYM UUID 是否匹配
一个最小可用的手动还原示例（Node.js）
```js
const { SourceMapConsumer } = require('source-map-js');
const fs = require('fs');
const mapData = fs.readFileSync('./dist/app.js.map', 'utf8');
const consumer = await new SourceMapConsumer(mapData);
const orig = consumer.originalPositionFor({
line: 152,
column: 27
});
// 输出：{ source: 'src/pages/Home.vue', line: 89, column: 12, name: 'onClickSubmit' }
```
只要输入的是真实报错的行列号，且 .map 文件准确，就能拿到原始位置。不需要源码文件本身，只依赖 .map 内容。
