contenteditable="true"不能直接用于协同编辑，因为它仅开启浏览器原生编辑能力，不产生操作日志、不广播变更、不感知他人修改，多人同时编辑会导致DOM覆盖、光标错乱和格式不一致。
contenteditable="true" 为什么不能直接用于协同编辑
它只是打开浏览器原生编辑能力的开关，不产生任何操作日志、不广播变更、不感知他人修改。多人同时写同一 contenteditable 元素，本质是各自改本地 DOM，结果必然覆盖或错乱——这不是 bug，是设计使然。
常见错误现象包括：两人在开头插入文字，一人内容消失；光标同步失败导致输入位置错乱；回车后 Chrome 插 <div></div>、Firefox 插 <br>，DOM 结构不一致，diff 失效。
- 必须显式设为
contenteditable="true"，contenteditable="on"或contenteditable="1"无效 - 所有祖先节点都不能有
contenteditable="false"，否则子元素即使设true也失效 - 必须加
tabindex="0"，否则键盘焦点不可达，document.execCommand和 Selection API 全部失活
MutationObserver + selectionchange 是唯一靠谱的监听组合
靠 input 事件捕获编辑动作？漏掉加粗、缩进、拖拽图片、右键粘贴富文本、中文输入法上屏——根本不可靠。DOMSubtreeModified 已废弃，且粒度太粗、性能差。
MutationObserver 监听 characterData 和 childList 类型变更，能精确到文本节点增删；配合 selectionchange 事件，才能拿到光标/选区变化，这对操作定位和光标同步至关重要。
立即学习“前端免费学习笔记（深入）”；
- 禁用默认粘贴：
onpaste="event.preventDefault()"，再用event.clipboardData.getData('text/plain')提纯文本 - 拦截回车：
keydown中对Enter调e.preventDefault()，否则格式彻底失控 - 不要用
innerHTML快照比对——不同浏览器生成结构不同，大文档解析慢，无法处理并发插入同一位置
协同状态必须走外部机制，不能依赖 DOM 自身
HTML 没有版本号、锁、时间戳或冲突检测机制。document 和 form 元素完全不感知“别人正在改”。所谓“冲突”，是你主动拉取服务端最新内容，与本地值做 diff 的结果。
可行路径只有两条：一是用 CRDT 或 oplog 实现操作级同步（如 Quill + ShareDB）；二是轻量方案——每次提交带版本号或哈希，服务端校验是否过期，返回 409 Conflict 并提示刷新。
- htmx 示例中，
hx-post="/save"请求需携带name="version"隐藏字段，服务端比对数据库当前 version - VS Code Live Share 这类工具绕开了 Git 文本合并，但遇到“一方删标签、另一方改 class”仍会丢内容，需人工确认
- 别用
localStorage存本地时间戳就宣称“防冲突”——它根本不跨设备、不同步
spellcheck="false" 和 oncontextmenu="return false" 是必加防护
拼写检查会干扰光标定位，尤其在中文输入场景下，光标可能意外跳转；右键菜单允许用户自由粘贴富文本甚至 script 标签，破坏 DOM 结构一致性。
这些不是“锦上添花”的优化，而是防止协同系统在真实用户操作下迅速崩溃的基础防线。
-
spellcheck="false"关闭拼写检查，避免光标异常跳转 -
oncontextmenu="return false"禁用右键菜单，防止非预期 DOM 插入 - 永远不要信任浏览器对
contenteditable的原生行为——它只为单人编辑设计，不是为协同而生
