HTML压缩在门户项目中必须与SSR、CDN、多语言模板深度耦合，否则易致白屏、JSON解析失败或SEO丢失；html-webpack-plugin的minify配置因SSR动态渲染而不生效，真实压缩点在服务端模板层或render hook中。
大型门户网站部署 HTML 压缩，不能只靠 html-minifier-terser 丢进构建流程就完事——它必须和 SSR 渲染链路、CDN 缓存策略、多语言模板系统深度耦合，否则极易导致首屏白屏、JSON 数据解析失败或 SEO 内容丢失。
为什么 html-webpack-plugin 的 minify 配置在门户项目里大概率失效
门户项目通常用 Node.js 做 SSR（如 Next.js、Nuxt 或自研模板服务），HTML 不是构建时生成的静态文件，而是每次请求动态拼接、注入数据后输出的流式响应。此时 html-webpack-plugin 根本不参与运行时 HTML 构建，它的 minify 配置自然不会生效。
- 常见错误：在 webpack 配置里写了
minify: { collapseWhitespace: true }，但实际返回的 HTML 依然满屏缩进和空行 - 真实生效点在服务端模板引擎层（例如 EJS、Nunjucks、Handlebars）或 SSR 框架的 render hook 中
- 若用 Express + EJS，需在
res.render()后拦截输出流，或改用支持压缩的引擎包装器（如ejs-minify） - Next.js 用户应检查
getServerSideProps返回的 HTML 是否经由renderToHTML流程，再决定压缩时机——推荐在next.config.js的experimental.optimizeFonts关闭前提下，用自定义server.js对res.write前的内容做预处理
collapseWhitespace 在门户首页引发 pre 和 script 内容错乱
门户首页常嵌入大量 <pre> 代码块、埋点脚本、JSON-LD 结构化数据，这些标签内的空白符是语义关键。启用 collapseWhitespace: true 默认会破坏它们，但 html-minifier-terser 并不自动识别所有上下文。
-
<pre>和<textarea>内容默认被保留，但前提是没手动覆盖preserveLineBreaks；而<script>里的模板字符串（如`<div>${name}</div>`）可能被minifyJS: true错误压缩，导致运行时语法错误 - 解决方案不是关掉
collapseWhitespace，而是精准排除：传入ignoreCustomComments: [/^jsonld:/, /^ga:/]，并在压缩前用正则提取并暂存所有<script type="application/ld+json">块 - 更稳妥的做法是分段压缩：先用
parse5解析 DOM，遍历节点，对非pre/script/style/textarea的文本节点调用trim()，再序列化回字符串——这样可控、可测、不依赖工具黑盒逻辑
多语言模板共用压缩配置导致中文注释乱码与占位符误删
门户往往一套模板渲染 zh-CN、en-US、ja-JP 多版本，模板中混用 EJS 语法（<% if (lang === 'zh') { %>）和 HTML 注释（<!-- 页脚版权信息 -->）。removeComments: true 会无差别清除二者，造成逻辑断裂。
立即学习“前端免费学习笔记（深入）”；
- 典型现象：压缩后
<% endif %>被删，模板渲染报错Unexpected token - 中文注释（如
<!-- 导航栏-用户中心 -->）在 Node.js 默认编码为latin1的环境下，会被html-minifier-terser错误解码为乱码，再转义成无效字符 - 必须统一入口编码：启动服务前设
process.env.NODE_OPTIONS = '--icu-data-dir=./node_modules/full-icu'，并在读取模板文件时显式指定encoding: 'utf8' - 避免用
removeComments，改用ignoreCustomComments: [/^%.*?%$/]排除所有 EJS 占位符，再单独走一遍正则删除纯 HTML 注释（<!--(?!%)[^]*?-->）
CDN 缓存与压缩结果不一致引发 TTFB 波动
门户流量高峰时，CDN 缓存的是未压缩 HTML，而应用服务器又开启了运行时压缩，导致同一 URL 在不同边缘节点返回不同体积的 HTML，Lighthouse 分数忽高忽低，缓存命中率下降。
- 根本矛盾：CDN 缓存的是原始响应体，而 Gzip/Brotli 是传输层压缩，与 HTML 内容压缩正交但不可叠加混淆
- 正确做法是“构建期压缩 + CDN 静态缓存”：SSR 输出前完成 HTML 压缩，再将结果写入 Redis 或本地文件缓存，CDN 回源直接拉取已压缩内容，不再二次处理
- 若必须运行时压缩，需确保所有边缘节点共享同一套压缩配置，并在响应头加
Content-MD5校验值，防止缓存污染 - 特别注意 Vary 头：若压缩逻辑依赖
User-Agent（如微信浏览器跳过collapseBooleanAttributes），必须返回Vary: User-Agent，否则 CDN 可能混存不同版本
真正卡住门户项目落地 HTML 压缩的，从来不是工具能力，而是模板动态性、多语言结构、CDN 分发层级带来的耦合点——这些地方一漏，压缩就从性能优化变成线上事故触发器。
