contenteditable仅控制编辑开关，不参与协同同步；协同需js捕获变更、构造操作、通过websocket分发；须用mutationobserver+selectionchange监听，禁用默认粘贴与回车，避免dom快照，推荐oplog或crdt方案。
contenteditable 本身不参与协同状态同步
它只是个编辑开关，打开后浏览器接管光标、输入、回车等行为，但所有变更都发生在本地 DOM，不会自动广播、不会序列化操作、也不会做冲突检测。所谓“协同”，必须由 JS 主动捕获变更、构造操作（如插入字符、删除节点）、通过 WebSocket 或类似通道发给服务端，再由服务端分发到其他客户端——contenteditable 在这个链条里只负责最前端的“用户能点进去写”这一步。
为什么直接监听 input 或 DOMSubtreeModified 不行
常见错误是给 contenteditable 元素绑 input 事件，指望它捕获所有编辑动作——但它漏掉太多：加粗、缩进、拖拽图片、右键粘贴富文本、撤销重做、甚至部分中文输入法上屏。更糟的是，DOMSubtreeModified 已被废弃，且触发太粗（整棵子树变就触发），性能差还不可靠。
实操建议：
- 用
MutationObserver监听characterData和childList类型变更，粒度更细、兼容性好 - 配合
selectionchange捕获光标/选区变化，这对光标同步和操作定位很关键 - 禁用浏览器默认粘贴：
onpaste="event.preventDefault()"，再用event.clipboardData.getData('text/plain')拿干净文本 - 回车必须拦截：
keydown中对Enter调e.preventDefault()，否则 Chrome 插<div></div>、Firefox 插<br>，格式完全失控
DOM 快照同步在协同场景下会崩溃
有人尝试定时取 innerHTML 发给服务端，让别人用 innerHTML = newHtml 覆盖——这在单人编辑时看似可行，一进协同就出问题：两人同时在开头插入文字，快照比对无法识别“并发插入同一位置”，结果必丢内容；DOM 解析慢，大文档卡顿明显；不同浏览器生成的 HTML 结构差异（比如换行标签）导致 diff 失效。
真正可用的路径只有两条：
- 走操作日志（oplog）：把每次变更转成带位置、类型、内容的操作对象，例如
{type: 'insert', pos: 12, text: 'hello'}，服务端合并后再下发 - 用 CRDT 算法：客户端本地维护一致状态，操作自带向量时钟，天然支持无序到达和冲突消解——但需引入
yjs或automerge这类库，不能靠contenteditable自己实现
移动端和输入法带来额外陷阱
在 iOS Safari 或安卓微信内置浏览器里，contenteditable 的 focus 行为、composition 事件时机、软键盘弹起逻辑都和桌面完全不同。典型现象：中文输入法正在组词时，input 事件没触发，但 compositionstart 和 compositionend 会触发两次，中间的字符若没被捕获，就直接丢了。
必须处理的点：
- 监听
compositionstart、compositionupdate、compositionend三件套，确保输入法上屏全过程可控 - 禁用
spellcheck="false"和autocorrect="off"，否则下划线干扰光标定位 - 不要依赖
document.execCommand——它在移动端基本不可用，且已被标准弃用 -
tabindex="0"必须显式设置，否则 iOS 上无法唤起键盘
contenteditable 把这个边界藏得太深：用户敲一个键、粘贴一段 Word、用鼠标拖拽移动文字，在底层可能是 3–7 次 DOM 变更。没做操作归一化，同步就注定是错的。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
