JavaScript Range.intersectsNode 为什么不同于整个节点被包含

先说结论：Range.intersectsNode(node) 判断的是“节点代表的区间和 Range 有没有交集”，不是“节点的全部内容是否都被 Range 包含”。只要选区穿过目标元素的一部分，结果就可能是 true。如果你的业务要求整个节点内容都在选区内，还要把节点内容转成一个 Range，再比较开始和结束两个边界。

官方地址：https://developer.mozilla.org/en-US/docs/Web/API/Range/intersectsNode

intersectsNode 判断的是“有交集”

我第一次用 intersectsNode() 时，直觉是把它当成“这个元素是否被选中”。但实际使用文本选择、批量标记或编辑器选区时，很快会遇到一个现象：选区只落在段落中间，段落节点仍然会返回 true。

原因在于 Range 表示的是文档树中的一段区间，而元素节点也可以看成父节点子列表中的一个区间。DOM 规范把目标节点在父节点中的位置看成从 (parent, index) 到 (parent, index + 1) 的范围。只要这个区间没有完全落在 Range 的起点之前或终点之后，就存在交集。

  
Range 可以覆盖一段文本。

const paragraph = document.querySelector("#intro");
const text = paragraph.firstChild;
const range = document.createRange();

// 只选中段落文本中间的一小段，不覆盖整个 p 节点。
range.setStart(text, 5);
range.setEnd(text, 8);

// 目标节点和 Range 仍有交集，所以这里可能是 true。
const overlaps = range.intersectsNode(paragraph);
console.log(overlaps);

这里的关键不是“段落被完整选中”，而是 Range 的两个边界落在了段落所覆盖的文档区间里。它回答的是“要不要把这个节点作为候选项”，并不回答“候选项的全部内容是否属于选区”。

把三个问题分开：交集、完整包含、文本命中

在接口设计上，我现在会先写清楚调用方真正想问的是什么。三个问题看起来相近，实际上对应三种判断：

如果直接把第一个问题的结果当成第二个问题，常见后果是给只选中半段的段落打上“已处理”标记，或者在批量操作中误把相邻元素一起纳入。intersectsNode() 本身没有错，错的是把“overlap”翻译成了“contains”。

完整包含要比较节点内容的两个边界

要判断一个元素的全部内容是否都在 Range 中，可以先用 selectNodeContents() 建立节点内容范围。这个方法把起点设为节点内容的开头，把终点设为节点内容的结尾；随后分别比较开始边界和结束边界。

function containsNodeContents(range, node) {
  // 不同文档树之间没有可比较的边界，先拒绝这类节点。
  if (node.getRootNode() !== range.commonAncestorContainer.getRootNode()) {
    return false;
  }

  const nodeRange = document.createRange();
  nodeRange.selectNodeContents(node);

  // range 的开始要不晚于节点内容开始，结束要不早于节点内容结束。
  const startsBefore =
    range.compareBoundaryPoints(Range.START_TO_START, nodeRange) = 0;

  return startsBefore && endsAfter;
}

compareBoundaryPoints() 比较的是当前 Range 和另一个 Range 的边界点。这里必须同时检查两端：只检查开始边界，会把“从节点开头开始、但在节点中间结束”的情况误判成完整包含；只检查结束边界也一样不够。

我会把这个辅助函数放在“批量处理节点”之前，而不是用 intersectsNode() 之后再凭经验猜测。这样接口名字和返回值的语义是一致的：intersectsNode 做粗筛，containsNodeContents 做严格判断。

节点树不同或节点已脱离 DOM 时，交集没有业务意义

Range 的边界点属于某一棵文档树。DOM 规范要求：如果目标节点的根节点和 Range 的根节点不同，intersectsNode() 返回 false。因此，从一个文档创建的 Range 不应该拿去判断另一个 iframe 文档里的节点，也不应该把已经移除的节点当作当前页面选区的一部分。

function sameTree(range, node) {
  // getRootNode() 能识别普通文档树和 Shadow DOM 树的根。
  return node.getRootNode() === range.commonAncestorContainer.getRootNode();
}

function intersectsInSameTree(range, node) {
  // 先确认比较对象属于同一棵树，再调用 Range API。
  return sameTree(range, node) && range.intersectsNode(node);
}

这个包装不是为了改变浏览器实现，而是把“可比较”的前置条件写进调用方协议。尤其是编辑器、预览区和 iframe 并存时，节点引用可能来自不同文档，先做树判断比事后解释一个 false 更容易维护。

折叠 Range 也要按任务定义边界

折叠 Range 的起点和终点相同，它更像一个插入光标而不是一段有长度的选择。此时用 intersectsNode() 判断“光标所在节点”可以作为粗略导航，但不能直接等价成“节点包含选区内容”。如果业务是寻找光标所在的段落，应结合边界点位置向上查找祖先；如果业务是判断文本是否被选中，则应先排除 range.collapsed。

function hasSelectedText(range) {
  // 折叠 Range 没有被选中的字符，直接返回 false。
  return !range.collapsed && range.toString().length > 0;
}

function canMarkNode(range, node) {
  // 标记操作要求完整包含，而不是只要有交集。
  return hasSelectedText(range) && containsNodeContents(range, node);
}

实际项目里的选择顺序

如果只是遍历文档、找出可能受选区影响的块级节点，先调用 intersectsNode()，再对候选节点做更细的文本或边界判断，成本和语义都比较合适。如果是删除、批量加标签、导出选区内容等不可逆或高影响操作，则应使用完整包含判断，并明确是否允许部分文本节点。

• 候选筛选：需要知道“有没有碰到”，使用 intersectsNode()。
• 完整节点操作：需要整个内容都在选区内，使用 selectNodeContents() 加两个边界比较。
• 文本级高亮：保留 Text 节点和字符偏移，不要把元素交集当成字符命中。
• 多文档场景：先确认 getRootNode() 相同，再执行比较。
• 光标场景：先看 range.collapsed，避免把插入点误判成有选中文本。

常见问题

intersectsNode 返回 true，是不是整个元素都被选中了？

不是。它只表示元素代表的区间和 Range 有交集，部分覆盖、Range 包含元素或元素包住 Range 都可能满足。

为什么不能只比较元素的 textContent？

textContent 只能告诉你文本内容，不能保留 Range 的边界节点和字符偏移。跨多个文本节点或包含嵌套元素时，仍然需要按 DOM 边界判断。

完整包含判断为什么要比较两次？

因为完整包含同时约束开始和结束。只约束一端，都会漏掉另一端越界的部分覆盖情况。

Range 可以判断另一个 iframe 里的节点吗？

不能把不同文档树的节点当作同一组边界点比较。先在对应文档中创建 Range，或者先检查根节点是否一致。