html压缩极限取决于浏览器解析器容错能力而非删减量，removecomments:true在前遇注释会触发旧版ie或嵌入式webview重解析；removeattributequotes仅安全移除满足特定条件的引号；gzip下removeoptionaltags可能增大数据体积，应优先启用collapsewhitespace和removecomments。
HTML 压缩不是“越狠越好”，真正卡住压缩极限的，是浏览器 HTML 解析器本身的容错边界——不是你删了多少空格，而是解析器在 tokenization 阶段是否还能正确识别 doctype、charset、标签嵌套和属性分隔符。
为什么 removeComments:true 在某些场景下反而拖慢解析
看似只是删掉 <!-- ... -->，但旧版 IE 或部分嵌入式 WebView（如 Android 4.x 的 System WebView）会在 开头、<meta charset> 之前遇到注释时，将其误判为「未知声明」，触发整页重解析（reparse）。这不是压缩失败，而是解析流程被中断后二次启动。
- 风险高发位置：
<!-- TODO: remove before prod -->出现在<meta charset="utf-8">之前 - 安全做法：用
ignoreCustomComments保留关键注释，或提前用正则提取<script type="application/json"></script>内容再单独 JSON 压缩 - 验证方式：用 Chrome DevTools 的 Network → Response Headers 查看实际返回的
Content-Type是否仍为text/html，而非降级成text/plain
removeAttributeQuotes 的安全边界在哪
这个选项只在属性值满足「无空格、无引号、不以数字开头、不含 / = <code>>」时才移除引号。一旦值里有 class="btn btn-primary" 或 data-id="123/abc"，html-minifier 就会跳过——它依赖的是内部的 isQuotedValueSafe 判断逻辑，不是简单正则替换。
- 常见翻车点：
src="https://example.com/a?x=1&y=2"→ 压缩后变成src=https://example.com/a?x=1&y=2，但&在未引号包裹时会被解析器截断为&实体，导致 URL 错乱 - 规避方案：对含查询参数的
src、href显式关闭该选项，或用customAttrSurround锁定特定属性 - 注意：SVG 中的
viewBox、xmlns等属性值含空格，removeAttributeQuotes默认不处理它们
压缩后体积下降 ≠ 实际加载变快
gzip 或 brotli 对高度结构化的 HTML 压缩率本身很高，盲目启用 removeOptionalTags（比如删掉 、
- 实测规律：Twitter 原始 HTML 207KB →
html-minifier压到 165KB，但 gzip 后从 48KB 变成 49.2KB - 真正有效的压缩项：优先开
collapseWhitespace和removeComments，它们对 gzip 友好；慎用removeOptionalTags和useShortDoctype - 关键提醒：Webpack 生态中若同时用
HtmlMinimizerPlugin和terser-webpack-plugin，别重复开启minifyJS，否则 UglifyJS 可能对已压缩的内联脚本二次损坏
压缩极限不在工具配置里，而在你能否让解析器第一遍就正确建树——所有激进选项都要拿真实 WebView 和低端设备跑一遍 document.readyState 检查，而不是只盯着文件大小数字。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
