不能直接用字符串diff做HTML增量更新，因为HTML文本等价性≠结构等价性，换行、属性顺序、动态token等非结构性变化会导致全量重传；必须基于DOM树语义化差异提取，配合服务端预计算结构指纹实现可靠增量。
直接比对 HTML 文档结构本身无法支撑可靠的增量更新——真正起作用的是基于 DOM 树结构的语义化差异提取，配合服务端预计算哈希摘要，才能避开字符串 diff 的雪崩效应和渲染阻塞。
为什么不能直接用字符串 diff 做 HTML 增量更新
HTML 字符串层面的 diff（比如用 diff-match-patch）在真实场景中极易失效：换行、空格、属性顺序变化、注释增删、JS 注入位置偏移，都会导致整段 hash 失配；一次 <div class="a"> 改成 <code><div class="a b"> 就可能触发后续所有块重传。这不是算法不够强，而是 HTML 作为“带语义的标记语言”，其文本等价性 ≠ 结构等价性。
<ul>
<li>浏览器解析后 DOM 节点顺序和结构才是真实渲染依据，字符串只是中间载体</li>
<li>服务端 SSR 输出常含动态时间戳、随机 nonce、CSRF token，每次生成文本不同但 DOM 结构一致</li>
<li>客户端 JS 渲染后插入的节点（如 React hydration 后挂载的 <code>data-reactroot）会污染 diff 结果
DOM 树 diff 才是可靠起点：如何提取可比结构指纹
关键不是比“长得像不像”，而是比“结构意图是否一致”。需先做标准化清洗，再生成轻量结构指纹：
- 剥离所有动态属性：
data-*、id（除非用于锚点）、style内联样式（保留 class）、nonce、timestamp类字段 - 归一化标签大小写与属性顺序（
class="a b"→class="a b"，不改为"b a"） - 将文本节点规范化为占位符：
textContent长度 > 20 时替换为[text:123]，避免内容微调引发全量变动 - 对每个元素生成结构哈希：
sha256(tagName + sortedClassNames + childCount + isVoid)，不包含子树内容
这样生成的指纹对非结构性变更免疫，且体积小（单节点约 32 字节），适合批量上传比对。
立即学习“前端免费学习笔记（深入）”；
服务端如何利用结构指纹做增量决策
客户端上传结构指纹列表后，服务端不是逐个比对，而是走两级索引加速：
- 第一级：按路径哈希（如
main > article > section:nth-child(2)）查缓存命中率，快速识别“整块未变” - 第二级：对路径内节点做局部树 diff，只返回
insert/update/delete的最小操作集（类似 JSON Patch，但面向 DOM 节点） - 操作指令必须带
selector定位（如section[data-id="post-123"]），而非 index 或 offset——因为 DOM 可能被 JS 动态 reorder
典型响应体：{"op":"update","selector":".content","html":"<p>New para.</p>"}，客户端用 element.innerHTML = ... 替换，不触发布局重排。
容易忽略的客户端陷阱：hydration 后的结构漂移
React/Vue 等框架 hydration 后，DOM 会悄悄补上缺失属性或调整结构（比如自动闭合 <img alt="HTML文档结构差异比对在网页增量更新中的底层优化策略" >、注入 data-reactroot），导致客户端生成的指纹和服务端原始结构不一致。必须在 hydration 完成后、首次 diff 前，主动执行一次“clean DOM”：
- 移除所有
data-reactroot、data-v-app等框架私有属性 - 过滤掉仅用于 JS 绑定的空
div（如<div id="portal-root"></div>） - 对
textContent做 trim，但保留换行符数量（因pre或white-space: pre场景需精确）
这步漏掉，后续所有增量逻辑都建立在错误基线上——表面跑通，实则每次都在传全量。
