contenteditable 仅启用编辑能力，光标同步、选区管理及并发冲突需 js 主动处理；必须用 selectionchange + settimeout 延迟读取、零宽 span 标记光标、crdt 逻辑位置传输，并弃用 innerhtml 全量替换。
contenteditable 本身不参与光标同步
它只负责让浏览器允许用户点击输入，光标位置、选区变化、多人并发下的定位偏移，全靠 JS 主动捕获和传输。直接监听 input 或靠 focus() 拉光标到开头，结果一定是错位或丢失——因为 getSelection() 返回的 anchorNode 和 focusOffset 在 DOM 结构被远程操作修改后立刻失效。
实操建议：
- 用
selectionchange事件触发光标采集，配合setTimeout(() => {}, 0)延后读取，避开渲染竞争 - 移动端 Safari 不稳定，点击场景下必须 fallback 到
document.caretRangeFromPoint(x, y) - 服务端只传逻辑位置（如 CRDT 偏移量
pos: 47或 DOM 路径["p", 0]），绝不传像素坐标{x: 120, y: 80} - 每个用户光标需独立插入带
data-user-id的零宽span，复用节点会导致样式覆盖和定位冲突
为什么 DOM 快照同步在协同中必然失败
定时取 innerHTML 发给服务端，再让别人用 innerHTML = newHtml 覆盖——这在单人编辑时能跑通，进协同就崩溃。两人同时在段首插入文字，快照比对无法识别“并发插入同一位置”，内容直接丢；不同浏览器生成的换行结构（Chrome 插 <div></div>，Safari 插 <p></p>）导致 diff 失效；大文档解析慢，滚动卡顿明显。
实操建议：
- 放弃
innerHTML全量替换，改用增量 DOM 更新（如insertBefore、replaceChild）保留节点引用 - 若必须重建结构，先用
el.textContent提取纯文本，再用DOMPurify.sanitize()过滤 HTML，限定ALLOWED_TAGS - 服务端收到内容后必须二次校验：剥离所有
data-属性、内联style、危险事件属性（如onerror）
冲突合并不能靠 contenteditable 自身机制
contenteditable 没有操作序列号、版本号或状态快照能力。它只是个开关，打开后所有变更都发生在本地 DOM，不广播、不序列化、不检测冲突。多人同时改同一个 div contenteditable="true"，结果必然是 DOM 覆盖、光标错位、格式丢失——这不是 bug，是设计使然。
实操建议：
- 真实状态必须存在协作引擎实例中（如
Y.Text或ShareDB.Doc），contenteditable只作视图层容器 - 变更捕获必须组合监听：
beforeinput（捕获格式操作）、paste（拦截并净化）、selectionchange（跟踪光标）、blur（兜底提交） - 禁用默认回车：
keydown中对Enter调e.preventDefault()，否则 Chrome 插<div></div>、Firefox 插<br>，格式失控 - 粘贴必须拦截：
onpaste="event.preventDefault()"，再用event.clipboardData.getData('text/plain')拿干净文本
切换 contenteditable 状态时光标总跳开头
直接调用 el.focus() 只是让元素获得焦点，不控制落点。浏览器按默认策略（首个文本节点起始、空 <p></p> 后崩溃、或上次 selection 缓存）决定位置，结果不可控。根源常是 DOM 结构污染：切换前已含空行、零宽字符、嵌套 <div> 或 <code><p></p>，导致 Range 无法合法 collapse。
实操建议：
- 切换前清空冗余子节点：
el.innerHTML = el.textContent || ''（保留纯文本结构） - 避免用
innerHTML = ' '占位——它会创建不可编辑的文本节点，干扰range定位 - 启用后手动构造
Range：range.selectNodeContents(el)→range.collapse(false)→sel.removeAllRanges(); sel.addRange(range) - 若内容为空，需先插入
（零宽空格）再操作，否则selectNodeContents返回空range
