纯HTML编辑器不支持diff，所谓差异高亮依赖外部JS库对标准化HTML做比对；htmldiff.js是最轻量方案但需合法输入、不处理script/style、输出为字符串；diffHTML适用于视图更新而非contentEditable；真局部更新应直接比对数据状态。
纯 HTML 编辑器本身不支持 diff，别在 contentEditable 里硬塞 DOM diff
HTML 编辑器（比如 contentEditable 或 textarea + 预览 iframe）只是容器，没有虚拟节点树、没 key 机制、也不做快照比对。你看到的“差异高亮”，全是 JS 库在背后标准化 HTML 后喂给 diff 引擎的结果。
常见错误现象：
- 直接用
oldEl.innerHTML === newEl.innerHTML判定是否变化 —— 浏览器自动补<tbody>、重排属性顺序，导致永远不相等 - 试图对
document.body做JSON.stringify()得到“快照” —— 实际返回空对象或报错，DOM 节点含循环引用 - 把
htmldiff.js的输出（带<ins>/<del>的字符串）直接插入contentEditable—— 标签被浏览器当作富文本解析，破坏结构
htmldiff.js 是最轻量可行的前端方案，但输入必须合法且预处理
htmldiff.js 不依赖框架，输出语义化 HTML 片段，适合插入只读预览区。但它不是万能胶水，几个实操约束必须满足：
- 输入必须是**合法 HTML 字符串**：不能含未转义的
&、<；若来自textarea，建议先用DOMParser解析再序列化，避免标签被误解析 - 不处理
<script>或<style>内容的深层 diff —— 整块当文本 token，只标“新增/删除”，不会比对内部 JS 逻辑 - 嵌套过深或含大量注释时性能下降；建议限制输入长度 ≤50KB，或加
Diff_Timeout = 1000防卡死 - 调用后返回的是字符串，不是 DOM 节点：
const result = htmldiff(oldHtml, newHtml); previewEl.innerHTML = result;
diffHTML 可用于构建可响应式编辑器 UI，但不是给 contentEditable 用的
diffHTML 是完整渲染库，适合替代原生 DOM 操作，但它面向的是「应用级视图更新」，不是「编辑器内容 diff」。它需要你定义组件函数、管理状态、显式调用 createRoot(...).render()。
立即学习“前端免费学习笔记（深入）”；
典型适用场景：
- 编辑器左侧写代码、右侧实时预览的双栏界面 —— 把预览区当成一个
diffHTML渲染根节点 - 待办列表、配置表单等动态 UI 区域，需频繁增删项且要保留滚动位置、焦点状态
- 不推荐用于
contentEditable容器本身：它无法接管富文本编辑行为，也无法处理光标、选区等复杂交互
关键区别：它靠虚拟节点树比对生成 patch，而 htmldiff.js 是字符串级 HTML 差异标记 —— 二者目标不同，不可混用。
真要局部更新表格或列表？绕开 diff 算法，直接比对数据状态
很多所谓“局部更新”需求，其实根本不需要 diff 算法。比如客户屏实时追加订单行、后台配置列表增删项——这些场景有明确数据源（XML/JSON），且结构扁平、顺序稳定。
更可靠的做法是跳过 HTML 字符串比对，直接比对数据状态：
- 提取当前 XML 中所有
STOKADI文本，形成数组xmlValues - 提取页面中已渲染的
.stokadi单元格文本，形成数组tableValues - 若
xmlValues.length > tableValues.length，说明有新增 —— 只 append 新行，不 touch 已有 DOM - 避免
$('#tableBody').empty()全量重绘，就能解决视觉抖动、滚动丢失、焦点中断问题
这种策略不依赖任何 diff 库，不碰 HTML 字符串解析，也不受浏览器自动修正干扰，反而更稳更快。
