Chrome 152 新增文本高亮边界查询：getClientRects 与 CSS Custom Highlight 的配合

做站内搜索时，命中词已经被标黄，但旁边的解释气泡总是漂在错误位置：文本一换行，气泡就偏了半行。Chrome 152 的发布说明把 OpaqueRange、getClientRects() 与 CSS Custom Highlight 的组合明确摆到了一起，前端可以把“找到文字”“拿到它占据的屏幕矩形”“绘制不改 DOM 的高亮”拆成三个可检查的环节。

这组能力适合搜索命中、批注和行内提示：先用 Range 得到真实文字边界，再用 CSS Custom Highlight 负责视觉标记；浏览器不支持时，保留普通文本和内联标记作为降级。

为什么一个命中词需要多个矩形

一个搜索词跨过行尾时，它在屏幕上并不是一个连续的盒子。Range.getClientRects() 返回的是这段 Range 占用的各个矩形，MDN 给出的返回值是可迭代的 DOMRect 序列。气泡定位若只取第一个矩形，第二行的命中就会被忽略；更稳妥的做法是按矩形集合计算包围范围，或选择离当前视口最近的矩形。

const range = document.createRange();
range.setStart(textNode, start);
range.setEnd(textNode, end);

const rects = [...range.getClientRects()];
const anchor = rects.at(0);
if (anchor) {
  tip.style.left = `${anchor.left + scrollX}px`;
  tip.style.top = `${anchor.bottom + scrollY + 8}px`;
}

这里的关键不是把数值写进气泡，而是确认 Range 已经绑定到真实的文本节点。节点为空、起止偏移越界或文字尚未布局时，矩形集合都可能为空，这些情况应该让提示隐藏，而不是把气泡定位到页面左上角。

Chrome 152 把哪条平台路线说清楚了

Chrome 152 稳定版发布于 2026 年 8 月 25 日。官方说明中，OpaqueRange 表示表单控件值中的一段活动文字范围，它只暴露值偏移，不暴露内部的 startContainer 和 endContainer；同时说明它可以参与 getBoundingClientRect()、getClientRects()、CSS Custom Highlight 和锚定弹出层。这意味着输入框里的建议词，不必为了定位而把控件内部文字当作普通 DOM 重新拼一遍。

这和传统内容区域的 Range 不是同一个对象。文章示例先用成熟的 DOM Range 讲清边界计算，再把 OpaqueRange 视作 Chrome 152 针对表单值提出的扩展方向；项目落地前仍应按目标浏览器实际能力测试。

用 CSS Custom Highlight 绘制命中词

高亮的职责可以从定位逻辑中分离出来。CSS Custom Highlight API 允许把 Range 放进 CSS.highlights，再用 ::highlight() 选择器设置背景色。这样不会为了每个命中词都修改正文 DOM，文字节点结构也更容易保持稳定。

const hit = new Highlight(range);
CSS.highlights.set("search-hit", hit);

::highlight(search-hit) {
  background: #ffe08a;
  color: #222;
}

视觉结果应该和定位结果分开验收：页面上能看到黄色标记，只能证明高亮注册成功；气泡是否贴着正确文字，还要单独检查 rects 的数量、坐标和滚动偏移。

把能力探测和降级放在同一条路径

当前实现可以把“标准能力”和“增强能力”分别判断。Range.getClientRects 已经是跨浏览器广泛可用的基础接口；CSS Custom Highlight 则需要检查 CSS.highlights 和对应的高亮选择器能力。增强能力不存在时，仍可用一个受控的 mark 元素包住搜索命中，并继续用 Range 计算气泡坐标。

function paintHit(range, text) {
  const canHighlight = globalThis.CSS?.highlights;
  if (canHighlight) {
    canHighlight.set("search-hit", new Highlight(range));
    return "custom-highlight";
  }

  const mark = document.createElement("mark");
  mark.textContent = text;
  return "inline-mark-fallback";
}

降级分支不要悄悄改变搜索结果的语义，也不要把用户输入当作 HTML 拼接。若必须生成 mark，应从可信文本节点拆分，保留原始字符内容，并在重新渲染前清理旧标记。

上线前要验证的三个细节

换行和滚动

让命中词跨两行，再滚动页面和滚动内部容器，检查多个 DOMRect 是否仍被正确处理。使用视口坐标时，不要重复加上容器的滚动量；转换到文档坐标时才需要合并页面滚动偏移。

输入框不是普通正文

OpaqueRange 的价值正好落在表单控件值这类封装内部。不要用普通 DOM Range 假设自己可以读取输入框的内部文本节点；在目标浏览器上确认对应能力后，再决定是否启用表单值高亮和锚定提示。

清理旧的高亮

搜索词变化时，先删除旧的 CSS.highlights 条目，再注册新的 Range；组件卸载时也要清理，否则长页面反复搜索可能留下过时的视觉状态。

相关问题

为什么不能只用 getBoundingClientRect

它更适合把整个对象看成一个盒子；多行文本需要 getClientRects() 返回的多个矩形，才能决定气泡贴在哪一行。

CSS Custom Highlight 会替代所有 mark 标签吗

不会。它减少了正文结构改写，但仍要考虑浏览器支持、可访问性和需要真实 DOM 节点的交互；不支持时保留安全的内联标记。

Chrome 152 发布说明代表所有浏览器已支持吗

不代表。发布说明描述的是 Chrome 152 的稳定版变化，跨浏览器兼容性仍应查看目标浏览器的实际实现和兼容数据。

小结

这次变化的实用价值在于边界信息更容易进入文本工具链：Range 负责指向文字，getClientRects 负责给出布局证据，CSS Custom Highlight 负责视觉层，OpaqueRange 则把同一思路延伸到表单控件值。把三层分别测试，再给增强能力保留清晰降级，搜索高亮、批注和锚定提示才不会因为一次换行就失准。