HTML压缩极限取决于浏览器解析器容错能力而非删减量，removeComments:true在<meta charset>前遇注释会触发旧版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">内容再单独 JSON 压缩 - 验证方式：用 Chrome DevTools 的 Network → Response Headers 查看实际返回的
Content-Type是否仍为text/html，而非降级成text/plain
removeAttributeQuotes 的安全边界在哪
这个选项只在属性值满足「无空格、无引号、不以数字开头、不含 / = < >」时才移除引号。一旦值里有 class="btn btn-primary" 或 data-id="123/abc"，html-minifier 就会跳过——它依赖的是内部的 isQuotedValueSafe 判断逻辑，不是简单正则替换。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 常见翻车点：
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（比如删掉 </li>、</p>）可能让原始文本更小，但 gzip 后反而增大 0.5–1KB——因为去除了可预测的重复闭合模式，降低了字典匹配效率。
立即学习“前端免费学习笔记（深入）”；
- 实测规律：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 检查，而不是只盯着文件大小数字。
