contenteditable 仅是编辑开关，协同需 JS 主动捕获变更、构造操作、分发合并；须组合监听 input/paste/blur/selectionchange 及 MutationObserver（subtree: true），禁用 attributes；协同必须用 oplog 或 CRDT 而非 DOM 快照，光标同步依赖 getSelection() + Range。
contenteditable 本身不参与协同状态同步，它只是个编辑开关。协同必须靠 JS 主动捕获变更、构造操作、分发、合并——所有这些，contenteditable 都不管。
为什么直接监听 input 或 DOMSubtreeModified 必然失败
给 contenteditable 元素绑 input 事件，看似能响应打字，但漏掉太多关键行为：加粗/缩进/拖拽图片、右键粘贴富文本、中文输入法上屏、撤销重做、甚至部分浏览器里回车后补发的变更。更麻烦的是，DOMSubtreeModified 已被废弃，触发粒度太粗（整棵子树变就触发），性能差且不可靠。
- 真正能覆盖多数编辑路径的是组合监听：
input+paste+blur+selectionchange -
paste必须e.preventDefault()，再用e.clipboardData.getData('text/plain')或'text/html'拿内容，否则 Word 样式或恶意脚本直接插入 DOM -
blur不是主力，但它是兜底：用户快速切 Tab 或点保存按钮时，input可能根本没触发
MutationObserver 是唯一靠谱的 DOM 变更监听方式
相比事件监听，MutationObserver 能精确捕获 characterData（文本节点修改）和 childList（子节点增删）两类变更，兼容性好、粒度细、不丢操作。
- 必须监听
subtree: true，否则嵌套结构里的变更收不到 - 不要监听
attributes，contenteditable自身属性变化和内容编辑无关 - 每次回调里要过滤掉非用户触发的变更（比如服务端同步回来的 patch 应用）
DOM 快照同步在协同场景下一定会崩溃
定时取 element.innerHTML 发给服务端，让别人用 innerHTML = newHtml 覆盖——这在单人编辑时还能凑合，一进协同就出问题。
立即学习“前端免费学习笔记（深入）”；
- 两人同时在开头插入文字，快照 diff 无法识别“并发插入同一位置”，必然丢内容
- 不同浏览器生成的 HTML 结构差异大：Chrome 插
<div></div>，Firefox 插<br>，diff 工具直接失效 -
innerHTML解析慢，大文档卡顿明显；且含内联style、data-属性等无关语义信息
协同必须用操作日志（oplog）或 CRDT，而不是 DOM 状态
协同编辑的本质不是“同步 HTML 字符串”，而是“同步用户意图”。比如“在光标位置插入‘hello’”、“删除第 3 个字符”，这些操作可序列化、可合并、可重放。
- 推荐用
oplog（操作日志）：每个客户端本地记录操作，服务端按时间戳或向量时钟排序后广播 - CRDT 更强但复杂度高，适合离线强需求；简单场景用带冲突检测的 oplog 就够用
- 光标/选区同步必须依赖
getSelection()+Range实时抓取，不能靠 DOM diff 推算
最容易被忽略的点是：协同编辑里，contenteditable 的唯一职责就是让用户能点进去写。其余所有事——监听、净化、序列化、分发、合并、光标定位——都得你亲手写清楚，浏览器不会替你多做半步。
