HTML压缩不是越狠越好，过度压缩会破坏浏览器Tokenizer解码和Tree Construction建树流程，导致重排、乱码或解析中断；必须禁用collapseWhitespace等对<pre><textarea>的处理，保留其语义空白，并确保<meta charset>为首标签、条件注释不被误删。
HTML压缩不是越狠越好；压缩过度会破坏解析流程、触发重排或乱码，反而拖慢首屏速度。 浏览器解析 HTML 是流式、单线程、自上而下的过程，任何影响 Tokenizer 字符解码或 Tree Construction 节点构建的操作，都可能让「体积变小」和「渲染变快」背道而驰。
为什么 collapseWhitespace 在 <pre> 和 <textarea> 里必须禁用
浏览器对 <pre>、<textarea>、<code> 的空白字符有明确语义要求：换行、缩进、空格都要原样保留。若工具误删其中的空白，会导致代码块显示错位、格式化失效，甚至破坏 JSON 配置文本的结构（比如把 {"a": 1, "b": 2} 压成 {"a":1,"b":2} 看似无害，但若原始内容含注释或换行分隔的多行字符串，就可能出错）。
html-minifier-terser 默认已规避这些标签，但如果你手动启用了 removeRedundantAttributes 或 collapseBooleanAttributes，仍可能间接干扰——例如删掉 <textarea wrap="off"> 中的 wrap 属性，改变默认换行行为。
- 务必确认压缩配置中
preserveLineBreaks: true已启用（尤其处理含代码示例的文档） - 避免在构建流程中对整个 HTML 字符串统一调用
String.prototype.replace(/\s+/g, ' ')，这种粗暴方式无法识别语义上下文 - 若模板含大量
<script type="application/json">，建议先提取再单独 JSON 压缩，而非依赖 HTML 工具的minifyJS
removeComments 删除注释时为何可能引发解析延迟
看似无害的 <!-- TODO: remove before prod --> 注释，在某些旧版 IE 或嵌入式 WebView 中，若出现在 <head> 开头、<meta charset> 之前，会被 Tokenizer 当作「未知声明」处理，导致编码识别失败，触发整页重解析（reparse）。这不是注释本身的问题，而是位置 + 编码声明缺失的组合陷阱。
立即学习“前端免费学习笔记（深入）”；
更隐蔽的是条件注释（如 <!--[if IE]>...<![endif]-->），现代工具默认不识别，直接删除后可能让依赖它的 polyfill 脚本失效，造成 DOM 构建中断。
- 生产构建前，用正则
/<!--\s*\[if.*?<!\[endif\]-->/gs扫描并人工确认是否真可删 - 所有
<meta charset>必须是<head>内第一个有效标签，压缩后检查其位置是否被注释“顶替” - 对含服务端注入逻辑的模板（如 PHP/SSR），注释可能包裹未执行的占位符，删注释=删逻辑
压缩后体积没降多少，但首屏 TTFB 却变长了？查这三点
常见假象：HTML 文件大小只减了 0.5%，但开发者工具 Network 面板里 domInteractive 时间却延长 200ms。问题往往不在压缩本身，而在压缩改变了资源加载节奏。
- 压缩工具若开启
minifyCSS，会把<style>标签内联 CSS 提取出来再压缩，若该 CSS 含@import或字体引用，可能触发额外网络请求，阻塞 parser - 使用
keepClosingSlash: false把<img/>改为<img>没问题，但若模板里混用 XHTML 风格的<link rel="stylesheet" href="a.css"/>，改写后变成<link rel="stylesheet" href="a.css">，部分老旧 CDN 会因缺少闭合标签拒绝缓存 - 压缩后所有属性值被去引号（
class=header），若 JS 用getAttribute('class')获取，通常不受影响；但若用el.class这种非标准访问，可能返回undefined，导致初始化脚本卡在 DOM 就绪前
真正关键的平衡点，从来不是「删了多少空格」，而是「浏览器拿到字节后，Tokenizer 是否能连续吐出 token，Tree Construction 是否能不间断建树」。一次错误的布尔属性压缩、一行被误删的 <meta>、一段被 flatten 掉的换行——都可能让解析器在某个节点突然停顿、回溯、甚至重来。压缩不是终点，是让解析器跑得更顺的起点。
