HTML无原生协作光标，需contenteditable容器+服务端同步+客户端渲染；禁用textarea；避免innerHTML替换；移动端用caretRangeFromPoint；WebSocket传逻辑位置而非坐标；各用户独立零宽光标节点；caret-color仅对焦点元素生效；悬停提示需JS浮层。
HTML 本身不提供协作光标能力，所谓“多人光标”是前端捕获 + 服务端同步 + 客户端渲染的组合结果，不是加个属性或标签就能启用的功能。
contenteditable 是唯一可行的容器选择
必须用 contenteditable="true" 的 div 或 article 作为编辑区主容器。所有协作逻辑都建立在这个基础上。
-
textarea不可用：它无法嵌入样式节点、选区在并发下极易错位、不支持beforeinput拦截、服务端同步后会重置滚动和焦点 - 避免 innerHTML 直接替换整段内容：这会让原有 DOM 节点引用失效，导致
getSelection().anchorNode返回null，触发Uncaught TypeError: Cannot read property 'getSelection' of null - 移动端 Safari 对
getSelection()支持不稳定，点击场景下应 fallback 到document.caretRangeFromPoint(x, y) - 读取光标位置推荐在
selectionchange事件中触发，并用setTimeout(() => {}, 0)延后执行，避开 DOM 渲染竞争
WebSocket 只传语义操作，不传像素坐标
别发 {x: 120, y: 80} 这类绝对坐标——字体差异、缩放比例、换行策略不同，各端光标必然错位。
- 正确做法是发送逻辑位置：例如
{type: "cursor-move", path: ["p", 0], offset: 12}（基于 DOM 路径）或{type: "cursor-move", pos: 47}（基于 OT/CRDT 文档偏移量） - 服务端只做广播或轻量合并，不做渲染；客户端各自解析并定位插入零宽节点
- 每个用户需独立创建自己的光标 DOM 元素（如带
data-user-id的span），复用同一个节点会导致样式覆盖和定位冲突 - 用
RangeAPI 插入光标节点后，调用getBoundingClientRect()获取真实像素位置，再套一层position: absolute容器显示头像+昵称
caret-color 控制本地光标色，但仅限当前焦点元素
caret-color 是唯一控制文本插入点颜色的 CSS 属性，但它只对当前获得焦点的可编辑元素生效。
立即学习“前端免费学习笔记（深入）”；
- 必须作用于实际承载光标的元素：如果光标落在嵌套的
span内，只给外层div设caret-color是无效的 - 动态切换颜色靠 JS：监听
focusin，拿到event.target，再设element.style.caretColor = "#4ecdc4" - 离开编辑状态时务必清理：否则后续用户可能继承错误颜色；尤其注意富文本编辑器中焦点可能漂移到隐藏
input或临时节点 - Safari 移动端对
contenteditable上的caret-color支持不可靠，部分版本会回退为系统默认色
悬停提示不能只靠 title 属性
title 是 HTML 原生唯一支持悬停的机制，但它是系统级 tooltip，无样式、无交互、移动端 Safari 常静默忽略。
- 适合只读标注，比如
<div title="张三正在查看">...</div>，但别指望它显示头像或换行 - 要自定义样式、加头像、支持点击，必须用
data-user-name+::before/::after伪元素生成提示层 - 伪元素方案限制明显：内容只能是字符串，不能插
<img>；悬停区域需设display: inline-block或块级，否则定位飘移 - 真正生产环境建议用 JS 驱动浮层（如 Popper.js），配合
mouseenter/mouseleave精确控制显隐
协作光标最难的部分不在“怎么画出来”，而在“怎么保持各端逻辑位置一致”。DOM 路径易断裂，字符偏移易受 invisible 字符干扰，CRDT/OT 同步算法一旦出错，光标就会卡死或跳变——这些底层问题没法靠改几个 CSS 或监听几个事件绕过去。
