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