[!info] related notes

• 所属 MOC: DevTools Sources MOC
• 面板: Sources 面板
• 本地验证: Overrides 与 Workspaces

DevTools Source Map vs Pretty Print

一句话关系

Source Map
→ 建立 generated code 与 original source 的位置映射

Pretty Print
→ 只让当前 generated code 更容易阅读

Pretty Print 不是 Source Map 的替代品。

Source Map 解决什么

现代构建可能经过：

• TypeScript transpile；
• JSX/Vue SFC transform；
• bundling；
• minification；
• code splitting。

浏览器执行的是生成后的 JS，但调试者希望回到原项目文件。

Source Map 记录这种映射关系，让：

• breakpoint；
• stack trace；
• source location；

能够尽量显示为原始源码位置。

Source Map 不保证什么

它不意味着：

• 线上真正执行原 TypeScript；
• 一定包含完整 original source；
• 所有 bundler transform 都能完美反向解释；
• 生产环境必须公开 .map 文件。

Source Map 是否部署、是否对公网暴露，需要结合错误监控、调试需求与源码暴露策略。

Pretty Print 解决什么

没有可用 Source Map 时，压缩代码可能只有一两行。

Pretty Print 会重新添加：

• 换行；
• 缩进；
• 基本结构格式。

让你至少可以阅读和下断点。

但它不能恢复：

• 被 minifier 改短的变量名；
• 原文件边界；
• TypeScript 类型；
• 原注释；
• 原模块结构。

选用顺序

有可信 Source Map
→ 优先原始源码视图

无 Source Map
→ Pretty Print generated code
→ 结合 Network / bundle / stack trace 继续定位

学习检查

1. Source Map 与 Pretty Print 各解决什么问题？
2. 为什么 Pretty Print 不能恢复原变量名和 TypeScript 类型？
3. Source Map 为什么只是映射，不代表浏览器执行原源码？
4. 生产环境不公开 Source Map 时，线上错误监控仍可能怎样利用私有 Source Map？
5. 一个 minified bundle 报错但没有 map，应如何降低定位成本？