上个月线上有个偶发的点击报错，堆栈最后一行指着 app.7f3a9c.js:1:45210。我把那个文件拖进编辑器，1.2 MB 的代码全挤在一行，光标按一下右箭头要走十几秒，语法高亮被迫关掉。那天我花了两个小时才学会读这种代码，也顺带明白一件事：压缩和美化不是同一个开关的正反两面，它们能给你的东西和给不了你的东西，其实完全不是一回事。
一、线上代码为什么会变成一行
JS 在发布前通常会被构建工具做三件事：把几十个模块合成一个 bundle，删掉所有多余的空白和换行，再把局部变量名换成单字母（这一步叫 mangle）。目的很直接——减少传输体积、减少解析成本。去掉空白和注释一般能让文件小 30%–50%，这就是几乎所有生产构建默认这么干的原因。
代价是可读性归零。于是报错堆栈里的行号几乎都是 :1: 开头，后面跟一个几万的数字。那个数是字符偏移，不是"第几万行代码"，很多人第一次看到会以为是行数，然后在一个只有一行的文件里翻半天。
二、读压缩代码的四种做法，和各自的代价
| 做法 | 能做到什么 | 局限 |
|---|---|---|
浏览器开发者工具里格式化（Sources 面板的 {}） | 把当前资源在面板里展开成多行，可以直接打断点 | 展开结果只存在于面板中，行号与原文件对不上；文件几十 MB 时面板会明显卡 |
| 编辑器的格式化命令 | 小文件方便，能存回磁盘继续搜索 | 对超过 1 MB 的单行文本很容易假死，有些编辑器超阈值直接放弃高亮 |
| 本地重新构建一份未压缩产物 | 最接近源码，变量名和文件名都在 | 要还原依赖和构建配置，跑一遍十几分钟；线上那份的提交版本对不上就白折腾 |
| 粘贴到在线格式化工具 | 只做排版，几秒看到函数嵌套结构 | 不会还原变量名，不能替你修 bug；超大文件同样会慢 |
这里有个概念要先掰开：美化不等于反混淆。美化只加换行和缩进，function e(t){return t*n+2} 展开一百行也还是 e、t、n。想把这些字母对回原来的名字，只有 source map（同目录下的 .map 文件）能做到。
三、我实际的处理顺序
- 先在堆栈里拿三个信息：文件名（含哈希）、行号、列号。哈希能确认报错的是不是当前线上那份，别在旧产物上找半天。
- 看看有没有 .map。有的话浏览器 Sources 面板直接对回源码，下面几步全部省掉。
- 没有 sourcemap 才动排版。把整段贴进 JS 美化压缩，缩进选 2 空格（同一屏能多看几十行），注释开关打开——有时残留的 license 头恰好告诉你这段来自哪个第三方库，这比省几行代码有用。
- 用列号做定位。美化后行号变了，但字符的相对位置没变，把
45210当成大致偏移去找。真正能搜的锚点是字符串字面量、接口路径、console文案和错误提示文本——这些是 mangle 唯一不会碰的东西。 - 拿到结构再谈复现。看到可疑函数后先在本地复现，不要试图在生产产物上"改回去"：改压缩产物是假动作，下一次构建就全没了。
同一天还有另一半问题在样式上，报错指向的 CSS 也是一整行，我用 CSS 美化压缩 展开后才发现是一个被覆盖的后层叠规则。接口返回的那串压成一行 JSON 也顺手丢进 JSON 格式化 展开，确认报错源头是少了一个字段，而不是页面逻辑写错——这一步差点让我白改半天 JS。
四、几个容易翻车的细节
- 行号一定会变。美化前是 1:45210，美化后可能变成第 780 行第 12 列。记录问题的时候把两组数字都写下来，否则第二天自己都对不上。
- 反向压缩有风险，风险在分号。去掉空白通常不改变运行结果，但如果源码依赖自动分号插入（ASI），换行一删，两句就粘成一句，可能直接变成语法错误。生产压缩交给构建工具，别自己手工把代码"删成一行"。
- 版权注释会被吃掉。以
/*! ... */开头的注释一般要求保留，压缩前后检查一遍，有些库缺了这条注释是不合规的。 - 美化不会修语法。括号本来就不配对的话，加再多换行也救不回来，报错只会让你以为"格式化工具坏了"。
- 压缩率统计是个有用的旁证。把疑似压缩过的文件压一遍，看原始字符数、结果字符数和压缩率：如果空白几乎没得去（变化不到 5%），说明它本来就是压缩产物，再压没有意义；正常未压缩的源码去掉空白和注释的收益往往在三成以上。
- 代码该不该贴进网页。这类工具是在浏览器本地完成处理、代码不发到服务器，但公司内部未公开的代码要不要放进任何一个在线页面，仍要先看团队的规定，浏览器扩展和代理日志这些环节不在工具的控制范围内。超大文件（几 MB）在浏览器里处理也会慢，那时候重新构建一份未压缩产物更划算。
五、常见疑问
Q：美化会不会改变代码逻辑？
不会。美化只增加换行和缩进，不删字符、不改语义，运行结果与原文件一致。
Q：为什么格式化之后跟报错的行号完全对不上？
因为你原来的行号只有一行，报错给的是列位置。展开成几百行之后行号必然变化，靠字符偏移去估算，或者靠字符串内容去搜索，比靠行号靠谱。
Q：能把 a、b、c 这种变量名还原回去吗？
格式化工具做不到，它只处理排版。还原名字需要构建时生成的 source map 文件；没有它，只能靠上下文的字符串和调用关系猜。
Q：压缩能省下多少体积？值得专门做吗？
去空白和注释本身常见收益是 30%–50%。但如果服务器已经开了 gzip 或 brotli，纯空白被压缩后重复度很高，实际传输节省会明显小于这个数字。真正的大头在删死代码、按路由拆包和把依赖打进公共 chunk。
Q：调试时用什么版本，上线又该留什么？
惯例是开发看美化版、生产部署压缩版，同时把未压缩产物或 sourcemap 留存下来给错误监控平台用。要留意 sourcemap 泄露的风险：把它上传到监控服务是可以的，但直接公开在公网等于把源码交给别人。
回头看那两个小时，真正卡住我的不是"代码看不懂"，而是一上来就想把整个文件读通。压缩产物不是给人逐行读的，它是给机器读的；人要做的是先用排版把结构立起来，再用字符串锚点切进去。有没有 sourcemap 决定了后面所有做法——有就用它，没有就美化加锚点，两条路都比硬盯着那一行强。