今年三月我接手过一个同事留下的邮件模板。文件是构建产物，整个 body 里几万个字符全挤在一行，编辑器里要横向滚四十多屏才能看到一个闭合标签。我要改的东西很小：某个 div 上的一个 class 名。结果找了将近二十分钟，中间还误删过一段被吞进同一行的注释。那天之后我给自己定了条规矩——拿到压缩过的源码，第一件事不是读，是先把它摊开；而反过来，要上线的页面我不舍得把结构缩进留着不动。
美化和压缩不是同一个动作的两面
很多人把这两个方向理解成"加换行"和"删换行"，好像来回做就能回到原样。实际上只有单向是可逆的：美化在标签嵌套关系上重新插入换行和缩进，压缩把所有空白和换行删掉。压缩后的文件里没有留下"原本在哪里换行、原来缩进几个空格"这些信息，你再美化一次，得到的是工具按嵌套层级重新排的版本，而不是原作者手写的那份。
这件事在版本管理里很要命。假设仓库里存的是压缩版，某次你把它摊开提交，diff 会把整份文件当成"一行删除、几百行新增"，谁也无法审。更常见的是另一种：前一个人用 2 空格，你用 4 空格重新格式化一遍再提交，于是每一行都被标记成改动，真正那两行改了什么完全被淹没。我做过的处理是——仓库里统一存一种形态（多数时候是美化版），压缩只发生在构建产物里，不进仓库；并且格式化时先选定缩进宽度，之后不随意切换。
<div class="wrap"><p>第一段</p><p>第二段</p><ul><li>条目</li></ul></div>摊开以后是下面这样。我关心的是层级一眼能看出来，闭合标签和开标签在同一个缩进深度：
<div class="wrap">
<p>第一段</p>
<p>第二段</p>
<ul>
<li>条目</li>
</ul>
</div>2 空格、4 空格还是 Tab，我的选择依据
用 HTML 美化压缩 时可以先选缩进方式，三个选项是 2 空格、4 空格、Tab。这个选择本身没有优劣，只有"和别人一致"的价值。我一般按嵌套深度来估：如果页面结构经常到第四第五层，2 空格在窄编辑器里不会把代码挤到屏幕右边，4 空格则看得更清楚。定下来之后有个可核对的规律——同一段结构换缩进宽度，每层的字符数是可以算的。
| 标签嵌套层级 | 2 空格缩进的前导空格数 | 4 空格缩进的前导空格数 | Tab 缩进 |
|---|---|---|---|
| 第 1 层 | 0 | 0 | 0 个 |
| 第 2 层 | 2 | 4 | 1 个 |
| 第 3 层 | 4 | 8 | 2 个 |
| 第 4 层 | 6 | 12 | 3 个 |
| 第 5 层 | 8 | 16 | 4 个 |
之所以我会专门去数这个：一旦从 2 空格切到 4 空格，第 5 层的行前面就多了 8 个空格，那一行的内容变了，diff 必然认为它被改过。反过来，如果两个人一个用 Tab 一个用空格，同一个文件在两种编辑器设置下看起来"错位"，其实是显示宽度不同，不是代码不同。
压缩删掉的那些空白，有一部分是渲染要用的
HTML 解析时会把源码里连续的空白和换行折叠成一个空格。所以平时标签之间换行、缩进，页面上看不出差别，这是美化的安全边界。但一旦涉及行内元素，那个被折叠出来的空格就存在了：两个用空格分隔的行内块之间，源码里换成回车，渲染出来通常仍然留着一个空格的宽度；靠把字号设成 0 来消掉间隙的写法，一旦空白处理发生变化，间距就跟着变。
更直接的是 pre 和 textarea 这类内容：里面的换行和空格本身就是要显示的东西，不能当成"格式噪声"删掉。HTML 美化压缩 的压缩模式对 pre、textarea 这类标签的内容是保留的，我自己压完也还是会 grep 一遍这两处，确认代码示例、签名框没被压平。
邮件模板是我最不愿意随手格式化的地方
回到开头那份模板。邮件的 HTML 和网页不是一套脾气：各家客户端对空白的处理不一致，行内元素之间的换行在某些客户端会真的变成一个空格宽度；表格单元格 display 设成行内块来排版时，源码里加个换行就可能把布局顶歪。所以我处理邮件模板的顺序是：先看是否需要摊开阅读，摊开只在"要读懂结构"那一步用，改完再压回去提交；如果这个文件本身是要上线的模板，我不会把美化后的版本直接塞进发送流程，而是先在自己这儿发一封测试邮件，看那几处依赖空白的间距有没有变化。
另一条经验是别把注释留在压缩后的行里。压缩之后一段注释可能把紧跟的代码吞掉——这是我那天误删注释之后才想明白的，模板里我用注释标记可编辑区域，压完必须确认这些标记还在。
什么时候美化，什么时候压缩
| 我遇到的情形 | 方向 | 理由 |
|---|---|---|
| 构建产物、线上抓下来的源码，全在一行 | 美化 | 要读结构、要定位某个标签 |
| 手写的 HTML 要发布，体积敏感 | 压缩 | 去掉换行与缩进，减少传输字符 |
| 要提交进仓库、要别人 review | 美化 | diff 只显示真正改动的行 |
| 邮件模板、含代码示例的页面 | 美化后检查、压缩前检查 | 空白参与渲染，pre、textarea 内容不能动 |
| 排查标签没闭合、层级混乱 | 美化 | 靠缩进深度发现错位的闭合标签 |
压缩这件事我会看工具给出的原始字符数、结果字符数和压缩率，但我不把它当性能结论用——一次压缩省的往往只是几百到几千个空白字符，页面快不快主要不是由这点空白决定的。这几个数对我真正的用处是"量级感"：压缩率异常高说明原来有大量空白，压缩率几乎为 0 说明这文件本来就是压缩过的，再压一次只是白做。
几件常被问到的
Q：美化会不会改变页面显示效果？
绝大多数情况下不会，因为标签之间的换行会被折叠成空白，浏览器忽略多余空白。会出问题的地方是 pre、textarea，以及依赖行内元素间距的写法，这两类要单独看。
Q：压缩以后出问题，能还原回去吗？
不能精确还原。原来的换行位置和缩进宽度没有被保存，压缩后再美化得到的是按层级重排的版本。所以我从不在唯一一份副本上做压缩。
Q：接手一行式的文件，我该整份摊开还是只摊片段？
整份摊开更省事，因为读结构要看全局；但要提交回去时，我会用压缩版覆盖，只把改动的那几处复制过去，避免格式化波及全文件。
Q：Tab 和空格哪个"更规范"？
没有哪个更规范，只有一个项目里只能用一种。Tab 的问题是显示宽度取决于编辑器设置，同一份文件两个人看到的对齐不一样；空格则永远一致。要混用时我倾向于统一转成空格。
Q：CSS 和 HTML 分在两个文件里，要不要一起处理？
我不会混着做。样式表的换行规则和影响面跟标签结构不同，我一般把样式那边单独走一遍，改完先看样式有没有塌陷，再动 HTML。
那个一行的邮件模板最后是改完了，我用的时间比预期长，不是因为找不到 class，而是因为摊开以后我发现结构本身有两处闭合标签位置不对——压缩的版本把这些都藏在一行里看不出来。现在我的判断标准是：要读懂、要审、要 debug，一律美化；要发布、要减体积，才压缩；而只要文件是别人要接着改的，仓库里那份就必须是可读的形态，压缩留在构建里。