node.comparedocumentposition 返回位掩码而非枚举，需用位运算判断节点文档流顺序；编辑器中应先确认同文档，再用 pos & node.document_position_following 等判断纯粹前后关系，并排除包含干扰。
Node.compareDocumentPosition 不是用来“排序节点”的工具，而是告诉你两个节点在文档流中的相对位置——它返回一个整数，你得用位运算去拆解。编辑器场景下（比如富文本 contenteditable 区域），节点顺序直接影响光标行为、选区计算、插入逻辑，直接比 === 4 或 === 2 极易出错。
为什么不能直接用 compareDocumentPosition 返回值判断“谁在前”
因为返回值是位掩码（bitmask），不是枚举。比如 20 表示“前者在后者前（4）且后者被前者包含（16）”，10 表示“前者在后者后（2）且后者包含前者（8）”。如果只写 if (pos === 4)，会漏掉所有组合值（如 20、36、44）；而 if (pos & 4) 才表示“前者在后者文档流之前”。
常见误判现象：
- 在
contenteditable中比较两个textNode，返回0（节点一致），但实际是同一节点两次引用 - 比较父元素和子元素，返回
20，误以为“只有前后关系”，忽略了包含关系对插入点的影响 - 跨 shadow DOM 边界调用，返回
1（DOCUMENT_POSITION_DISCONNECTED），但没做检查，后续逻辑直接崩溃
怎么安全判断两个节点在编辑器中的文档流先后顺序
核心是：只关心 DOCUMENT_POSITION_PRECEDING（2）和 DOCUMENT_POSITION_FOLLOWING（4）这两个标志，并排除包含关系干扰（否则“在前”可能只是父子嵌套，不是线性顺序）。
实操建议：
- 先确认节点属于同一文档：
if (nodeA.ownerDocument !== nodeB.ownerDocument) return null - 用位与判断纯粹的前后关系：
const pos = nodeA.compareDocumentPosition(nodeB); if (pos & Node.DOCUMENT_POSITION_FOLLOWING) → nodeA 在 nodeB 后 - 若需排除父子影响（比如只看兄弟级顺序），加额外过滤：
!(pos & (Node.DOCUMENT_POSITION_CONTAINS | Node.DOCUMENT_POSITION_CONTAINED_BY)) - 注意：文本节点的起始位置不等于其父元素位置，若要精确到字符偏移，必须结合
textContent和node.textContent.length计算
在 contenteditable 编辑器中容易踩的坑
编辑器里节点动态生成频繁，compareDocumentPosition 的结果极易受 DOM 变动干扰：
- 光标位于空
<div><br></div>内时，br节点和父div的位置关系是20，但用户感知是“光标在段落开头”，不是“br在div前” - 使用
Range获取的startContainer和endContainer可能是文本节点，而你想比较的是包裹它们的块级元素 —— 必须先用parentNode归一化，否则位置关系无意义 - IE11 及更早版本不支持该方法，若需兼容，得 fallback 到
sourceIndex（仅 IE）或基于TreeWalker的遍历计数，但性能差很多 - Shadow DOM 中的节点无法与 light DOM 节点直接比较，返回
1是常态，别试图绕过这个限制
最常被忽略的一点：这个方法不处理“视觉顺序”，只处理“文档顺序”。编辑器里 CSS flex-direction: row-reverse 或 transform: scale(-1) 会让视觉前后和文档前后完全相反——compareDocumentPosition 依然按 HTML 结构返回，不会管样式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
