contenteditable="true" 本身不支持协同编辑，仅实现本地输入；必须结合 mutationobserver、selectionchange、操作日志（oplog）或 crdt 等机制才能实现可靠协同。
contenteditable="true" 为什么一开就同步失败
它根本不参与协同状态同步，只负责让浏览器接管光标和输入行为。所有变更都锁在本地 DOM，不会自动序列化、广播或做冲突检测。多人同时编辑时内容覆盖、光标乱跳、DOM 结构不一致，不是 bug，是设计如此。
常见错误包括：document.getElementById("editor").contentEditable = true 后直接扔给用户用；或指望 input 事件捕获全部操作——但它漏掉加粗、缩进、拖拽图片、中文输入法上屏、甚至右键粘贴富文本。
- 必须用
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）或 CRDT，而不是状态快照。
- 服务端不能存 HTML 字符串，应存结构化操作：{type: 'insert', pos: 12, text: 'hello'}
- 客户端收到操作后，需在本地状态上做无冲突合并，而非直接替换 DOM
- 避免任何依赖浏览器解析 HTML 的路径，如
innerHTML = htmlString或DOMParser.parseFromString
父级 contenteditable="false" 会静默锁死子元素
即使子元素显式写 contenteditable="true"，只要任意祖先节点设了 contenteditable="false"，整个子树都会不可编辑。“就近 false 优先”是规范行为，不是 bug。
更隐蔽的是：只写 contenteditable（无等号无值），旧版 Safari 行为不稳定；写成 contenteditable="on" 或 contenteditable="1" 是无效值，浏览器当它不存在，退化为 inherit，可能意外继承父级 false。
- 务必显式写
contenteditable="true"，并逐层检查祖先节点是否含contenteditable="false" - 用 JS 动态开关时，别只改属性值，还要同步处理
tabIndex：el.tabIndex = enable ? 0 : -1 - 禁用编辑后，建议移除
tabIndex或设为-1，避免产生不可见但可聚焦的“幽灵焦点”
为什么 tabindex="0" 是协同编辑的前提条件
contenteditable="true" 本身不赋予聚焦能力。<div>、<code><p></p> 等非表单元素默认不可被键盘聚焦，漏掉 tabindex="0"，用户点鼠标能打字，但 Ctrl+B、Ctrl+I 等快捷键完全没响应——因为没焦点，document.execCommand 和 Selection API 全部失效。
某些旧版 Safari 对 tabindex 缺失更敏感，光标点击后瞬间消失；若父容器有 overflow: hidden 且内容溢出，tabindex="0" 有时会触发滚动跳变。
- 必须显式加
tabindex="0"，这是所有后续交互（加粗、换行、粘贴拦截）的前提 -
tabindex="-1"只支持 JS 主动聚焦（el.focus()），无法进 Tab 链，不适合用户自主操作场景 - 移动端点不到？先确认是否设置了
tabindex="0"，再检查是否有user-select: none或pointer-events: none干扰
