compareDocumentPosition 是 DOM 节点方法，返回位掩码描述两节点相对位置，不能直接判断选区顺序，因它只接受 Node 实例、不支持 Range/Selection，且返回 0 仅表示同一节点而非位置相等。
compareDocumentPosition 是什么，它能直接判断选区顺序吗
compareDocumentPosition 是 DOM 节点上的原生方法，返回一个位掩码数字，描述两个节点在文档中的相对位置关系。它**不接受 Range 或 Selection 对象**，只接收两个 Node 实例（比如 Element、Text）。所以不能直接传入 getSelection().getRangeAt(0) 这类选区对象——这是第一个常见错误。
你得先从选区中提取出有代表性的节点，通常是：
-
range.startContainer 和 range.endContainer（但它们可能不是有意义的比较锚点）
- 更稳妥的是取
range.commonAncestorContainer 下的最浅层文本节点，或用 range.startContainer 和 range.endContainer 沿父链向上归一到最近公共祖先后，再比较其在树中的偏序
怎么安全提取可比节点来判断光标/选区先后
对编辑器内任意两个选区（比如用户拖拽起点和终点、或两个独立 Range），推荐用以下方式提取“文档顺序锚点”：
range.startContainer 和 range.endContainer（但它们可能不是有意义的比较锚点）range.commonAncestorContainer 下的最浅层文本节点，或用 range.startContainer 和 range.endContainer 沿父链向上归一到最近公共祖先后，再比较其在树中的偏序Range），推荐用以下方式提取“文档顺序锚点”：
取每个 Range 的 startContainer 和 startOffset，然后用 node.nodeType === Node.TEXT_NODE ? node : node.firstChild 尝试落到文本节点；如果不行，就用 range.cloneContents().firstChild（代价稍高但语义明确）。
- 对每个
Range，调用range.startContainer.compareDocumentPosition(range.endContainer)只能告诉你容器关系，不够细 - 真正要判断“哪个选区在前”，应统一用
range.startContainer+range.startOffset构造一个虚拟位置点，再用document.createTreeWalker或递归遍历计算文档中所有文本节点的全局字符偏移（DOM Level 3 的Range.prototype.compareBoundaryPoints更合适，但已被废弃） - 实际项目中，90% 场景只需比较两个
Range的startContainer和startOffset是否满足a.compareDocumentPosition(b) & Node.DOCUMENT_POSITION_FOLLOWING
为什么 compareDocumentPosition 返回 0 却不代表两节点相同
compareDocumentPosition 返回 0 表示两节点是**同一个节点**（a === b），不是“位置相等”。如果你传入的是两个不同 Text 节点，哪怕内容一样、相邻、甚至 offset 都为 0，结果也不会是 0。
常见陷阱：
- 误把
range1.startContainer 和 range2.startContainer 直接比较，而它们可能是不同 Text 节点，即使视觉上紧挨着
- 没检查返回值是否含
Node.DOCUMENT_POSITION_DISCONNECTED（比如跨 shadow root 或 iframe），这时比较无意义
- 没做位运算判断：正确写法是
(a.compareDocumentPosition(b) & Node.DOCUMENT_POSITION_FOLLOWING) !== 0，而不是 === Node.DOCUMENT_POSITION_FOLLOWING
编辑器中真正可靠的顺序判断策略
在富文本编辑器（如 Slate、ProseMirror 或自研 contenteditable）里，靠单次 compareDocumentPosition 很难覆盖所有 case。更健壮的做法是：
- 把两个
Range 都标准化为“文档内扁平化位置”：用 range.startContainer 开始，沿 parentNode 向上直到 document.body，记录每层索引，最后拼成路径数组（如 [0, 2, 1]），再逐项比较
- 或者用
Range.prototype.cloneRange() + range.setStartBefore(node) + range.toString().length 算前缀长度（适合纯文本场景）
- 现代方案倾向用
document.caretRangeFromPoint(x, y) 或 getSelection().anchorNode + focusNode 配合 compareDocumentPosition 做粗筛，再用 Range.prototype.intersectsNode() 辅助判定重叠关系
真实编辑器逻辑里，compareDocumentPosition 只是其中一环，单独依赖它容易漏掉 text node 分裂、br 换行、zero-width space 等边界情况。真正要稳定排序选区，得结合节点路径 + offset 归一化 + 文本内容校验。
range1.startContainer 和 range2.startContainer 直接比较，而它们可能是不同 Text 节点，即使视觉上紧挨着Node.DOCUMENT_POSITION_DISCONNECTED（比如跨 shadow root 或 iframe），这时比较无意义(a.compareDocumentPosition(b) & Node.DOCUMENT_POSITION_FOLLOWING) !== 0，而不是 === Node.DOCUMENT_POSITION_FOLLOWING
compareDocumentPosition 很难覆盖所有 case。更健壮的做法是：
- 把两个
Range都标准化为“文档内扁平化位置”：用range.startContainer开始，沿parentNode向上直到document.body，记录每层索引，最后拼成路径数组（如[0, 2, 1]），再逐项比较 - 或者用
Range.prototype.cloneRange()+range.setStartBefore(node)+range.toString().length算前缀长度（适合纯文本场景） - 现代方案倾向用
document.caretRangeFromPoint(x, y)或getSelection().anchorNode+focusNode配合compareDocumentPosition做粗筛，再用Range.prototype.intersectsNode()辅助判定重叠关系
compareDocumentPosition 只是其中一环，单独依赖它容易漏掉 text node 分裂、br 换行、zero-width space 等边界情况。真正要稳定排序选区，得结合节点路径 + offset 归一化 + 文本内容校验。
