浏览器解析时将标签间连续空白折叠为单个空格，但仅限普通文本节点；pre、script、style等特殊上下文保留原始空白；DOM构建后残留的空文本节点需用element.normalize()显式清理。
浏览器解析时怎么处理标签间的空格和换行
HTML 解析器对空白的处理不是“删除”，而是“折叠”：多个空格、制表符、换行符在文本节点中被合并为单个空格；但仅限于普通文本内容区域。
关键点在于，这个折叠发生在 DOM 构建阶段，且只影响 Text 节点的 nodeValue，不改变节点结构本身。
-
<div>\n <p>hello</p>\n</div>中的换行和缩进会被忽略，div的childNodes仍包含一个空Text节点（哪怕它只含换行符） -
<pre> a b </pre>内部空白完全保留，因为pre是预格式化上下文 -
<script>和<style>内部也按原始字符串解析，不折叠
所以，“冗余空格是否被合并”取决于它所处的上下文类型，而非一概而论。
normalize() 不是解析器的一部分，但它能清理解析后残留的空文本节点
element.normalize() 是 DOM 方法，不是 HTML 解析流程中的自动步骤。它只在你显式调用时运行，作用是：
- 合并相邻的
Text节点（如"a"+"b"→"ab"） - 移除
nodeValue === ''的空Text节点（比如只含换行或空格的节点）
常见误用：
- 对未挂载的元素提前调用：
const el = document.createElement('div'); el.normalize();—— 无子节点，什么也不做 - 对字符串直接调用：
htmlString.normalize()—— 不存在该方法，会报错 - 期望它压缩文本内部空格：
"a b"不会变成"a b"，得用.replace(/\s+/g, ' ').trim()
正确姿势是：
立即学习“前端免费学习笔记（深入）”；
- 先把 HTML 字符串注入
template.innerHTML - 再对
template.content调用normalize() - 最后取
template.innerHTML或遍历content.childNodes
用 html-minifier 压缩源码时 collapseWhitespace 的真实行为
collapseWhitespace: true 并非简单删掉所有空白，它模拟了浏览器的折叠逻辑，但更激进：
- 安全移除标签之间的空白（如
<div><p>中的换行） - 把块级元素间的多个空白（包括换行+空格）压缩为单个空格或直接删除，取决于上下文
- 默认不触碰
<pre>、<textarea>、<script>、<style>内容 - 若开启
conservativeCollapse: false（默认），还会合并内联元素间的空白，可能导致<span>a</span> <span>b</span>渲染为"ab"（无空格）
性能方面：
- 单次压缩耗时通常在毫秒级，对构建流水线影响极小
- 但若在服务端每次响应都实时压缩（如 Express 中间件），需注意正则匹配开销，尤其大文件时建议缓存结果
为什么服务器端 gzip 比手动删空格更值得优先投入
HTML 文件中，纯空白字符（空格、换行、制表符）在 gzip 压缩下几乎不占体积 —— 因为它们高度重复，LZ77 算法能高效编码。实测显示：
- 一个 12KB 的未压缩 HTML，手动删空格后变 9KB，再 gzip → 3.1KB
- 同样 12KB 原始 HTML 直接 gzip → 3.2KB
差距不到 3%，而删空格可能引入布局风险（如 inline-block 元素间换行导致像素间隙）。
真正影响传输体积的是：
- 未压缩的图片（尤其是 PNG/JPEG）
- 未 tree-shake 的 JS/CSS
- 重复引入的字体文件或图标雪碧图
所以，与其花时间写正则清理空格，不如确认 Nginx 开启了 gzip_static on，并检查资源是否已启用 Brotli（比 gzip 高约 15% 压缩率）。
实际项目里，DOM 层面的空文本节点问题，往往比源码空白更隐蔽：它们不增加体积，却让 textContent 提取不准、childNodes.length 失真、遍历时多出无效项 —— 这才是 normalize() 最该出场的地方。
