HTML无法直接实现多人实时协作光标，需WebSocket+OT/CRDT服务端同步与客户端绝对定位渲染；contenteditable是必需容器，textarea因无样式隔离、不可靠选区等不适用。
HTML里没法直接实现多人实时协作光标
浏览器原生HTML不提供协同编辑能力，contenteditable 或 textarea 都是单人操作域。所谓“实时光标”，本质是服务端同步+客户端渲染的组合结果，不是靠某个HTML标签就能打开的开关。
常见错误现象：Uncaught TypeError: Cannot read property 'getSelection' of null（误以为监听本地 selection 就能推给他人）、光标位置在不同设备上偏移、输入延迟或冲突合并失败。
- 真实场景必须依赖 WebSocket 或类似长连接通道，把用户操作（如插入、删除、选区变化）序列化为 OT（Operational Transformation）或 CRDT 操作指令
-
selectionchange事件只反映当前页面的选区，不能跨浏览器广播；需手动捕获并发送到服务端，再由服务端分发到其他客户端 - 光标渲染本身要用绝对定位 + DOM 节点包裹（比如用
span包住一个零宽字符），否则无法在富文本中精确定位
用 contenteditable 搭配 getSelection() 获取本地光标位置
这是所有协作编辑前端的第一步：准确读取当前用户光标落在哪。但要注意，getSelection() 返回的是全局对象，必须结合 anchorNode 和 focusOffset 计算逻辑位置，不能直接当坐标用。
使用场景：用户移动光标、点击某段文字、键盘触发输入前——都需要立刻采集一次选区快照。
- 别在
input事件里读getSelection()，它可能已被后续渲染覆盖；推荐用setTimeout(() => {}, 0)微任务延后读取 - 如果编辑区被
innerHTML重写过，原有 DOM 节点引用失效，anchorNode可能变成null；应优先用Range的cloneContents()做安全快照 - 移动端 Safari 对
getSelection()支持不稳定，需 fallback 到document.caretRangeFromPoint(x, y)（仅限点击触发）
为什么不能用 textarea 做协作编辑的主容器
textarea 是纯文本控件，不支持内嵌元素、样式隔离、光标跨行高亮等协作必需能力。它的 selectionStart/selectionEnd 看似简单，但在多人并发下会迅速失准。
性能影响：每次服务端下发新内容，若用 value = newText 替换，会强制清空光标、滚动条归零、触发重排；而 contenteditable 可局部更新 DOM 节点，保留更多上下文状态。
-
textarea无法区分“用户输入”和“服务端同步来的变更”，导致 undo 栈混乱、光标跳变 - 没有
beforeinput事件支持（Chrome 62+ 才有，且兼容性差），拦截/转换输入行为困难 - 移动端软键盘唤起时，
textarea的scrollIntoView()行为不可控，协作中常出现光标被遮挡却无法自动滚动
协作光标 UI 渲染必须绕开 document.execCommand
document.execCommand 已废弃，且在协作场景下会破坏操作可追溯性——它不返回操作描述，也不暴露底层 DOM 变更路径，导致 OT 合并失败率飙升。
正确做法是：所有编辑动作都走自定义指令（如 { type: 'insert', pos: 12, text: 'hello' }），光标渲染用独立 div 浮层 + getBoundingClientRect() 定位，与编辑内容 DOM 解耦。
- 不要用
insertNode直接插 DOM，应统一走 patch 函数，确保每次变更都能生成可序列化的逆操作 - 多个用户光标需用不同颜色边框 + 用户名 label，但 label 绝对定位的
top/left必须基于编辑容器的getBoundingClientRect()计算，不能依赖offsetTop - 光标浮层的
z-index要高于所有编辑内容，否则会被富文本中的iframe或canvas遮挡
真正难的不是画出一个光标，而是让十个用户的光标在三次网络往返后仍指向同一语义位置。这要求光标坐标必须绑定到逻辑字符索引（而非 DOM 偏移），而逻辑索引又依赖服务端做最终锚定。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
