一个常见的痛点：内容插入导致视口跳动
你在阅读一篇长文章时，页面顶部突然插入了一条广告横幅或一段推荐内容，整个文档瞬间向下移动，你原本注视的文字跑到了视口之外。这种体验在动态加载内容的页面中尤为常见：聊天窗口不断接收新消息、信息流刷新拉取新帖子、评论区加载更多回复。用户没有滚动，视口却自己动了，阅读位置丢失，甚至可能误触到不想点的链接。
直觉上，解决这个问题似乎需要 JavaScript 介入：在插入内容前记录当前滚动位置，插入后重新设置 scrollTop。但这种方式存在明显缺陷——它无法感知内容高度的变化发生在视口内还是视口外，也无法区分用户主动滚动与布局被动偏移。更关键的是，如果插入操作发生在滚动容器的顶部，单纯恢复 scrollTop 并不能保持视口内容的相对位置，因为新内容把原有内容向下推了，你需要补偿的是这个位移量，而不是简单恢复数值。
2017 年前后，Chrome 的开发者们在处理类似问题时意识到，浏览器本身可以在布局阶段自动完成这种补偿。于是诞生了滚动锚定（Scroll Anchoring）机制，并最终成为 CSS Scroll Anchoring Module Level 1 规范的一部分，通过 overflow-anchor 属性暴露给开发者。这个机制的目标很直接：当页面布局因 DOM 变化而改变时，自动调整滚动位置，让用户正在看的内容保持原位。
滚动锚定的核心机制：锚节点的选择与位置追踪
滚动锚定的工作方式可以拆解为三个步骤：选择锚节点、记录锚节点位置、在布局变化后调整滚动偏移。
当用户滚动到一个滚动容器（比如文档视口或一个设置了 overflow: scroll 的 div）的某个位置时，浏览器会在当前可见区域内寻找一个“锚节点”（anchor node）。这个节点是后续所有位置补偿的参照物。锚节点的选择并非随机，浏览器会优先考虑视口上部的元素，尤其是那些具有明确语义的块级元素，比如段落、列表项、标题等。如果某个元素刚刚发生过布局变化，它的相邻节点也可能成为候选。一旦选定，浏览器会记录锚节点相对于视口顶部的偏移量。
之后，当容器内发生布局变化——例如新元素插入到锚节点上方——浏览器会重新计算锚节点的新位置。假设锚节点原本距离视口顶部 100px，新内容插入后它被推到了 150px 处，浏览器就会自动把滚动位置向下调整 50px，让锚节点重新回到 100px 的位置。这样，用户的视线焦点就被“钉”在了锚节点上，视口内容保持稳定。
这个调整发生在浏览器的布局阶段，而不是通过 JavaScript 的 scrollTop 赋值。它由浏览器内部的滚动锚定算法自动完成，对开发者来说几乎是透明的。overflow-anchor 属性就是用来控制这个行为是否对某个元素生效的开关。
overflow-anchor 的取值与默认行为
overflow-anchor 的语法非常简单，只有两个关键字值：auto 和 none。默认值是 auto，意味着元素可能成为滚动锚定的候选锚节点。none 则明确表示该元素不会被选为锚节点。这个属性适用于所有元素，不继承，计算值就是指定的关键字，动画类型是离散的（即不能平滑过渡）。
值得注意的是，滚动锚定在支持它的浏览器中是默认启用的。也就是说，只要浏览器实现了这个机制，你什么都不用做，它就会自动工作。overflow-anchor 属性的存在，主要是为了让你在遇到问题时能够关闭它。MDN 文档明确指出：“默认情况下，在任何支持滚动锚定行为的浏览器中都将其启用。因此，仅当你在文档或文档的一部分中遇到滚动锚定问题并且需要关闭行为时，才通常需要更改此属性的值。”
这意味着，大部分开发者其实不需要主动设置这个属性。但当你发现某些场景下滚动锚定产生了副作用——比如它阻止了你期望的滚动行为，或者导致奇怪的跳动——你就需要知道如何用 overflow-anchor: none 来排除特定元素。
一个贯穿全文的场景：实时聊天窗口
为了具体说明滚动锚定的行为，我们用一个实时聊天窗口作为贯穿场景。假设有一个消息列表容器，新消息不断从顶部插入（类似于某些直播弹幕或聊天室）。用户正在查看较早的消息，此时新消息插入，如果没有滚动锚定，整个消息列表会被向下推，用户看到的内容会突然跳开。
这个场景非常适合观察滚动锚定的效果，因为新内容插入的位置（顶部）与用户关注的位置（下方某条消息）之间存在明确的相对位移。我们可以在容器上设置 overflow-anchor: auto（默认），然后观察浏览器如何保持用户正在阅读的那条消息稳定。
下面是一个简化的 HTML 结构：
<div class="chat-container" style="overflow: scroll; height: 300px;">
<div class="message">用户A：你好</div>
<div class="message">用户B：在吗？</div>
<div class="message" id="anchor">用户C：我们讨论一下方案</div>
<!-- 更多消息 -->
</div>当新消息通过 insertAdjacentHTML('afterbegin', ...) 插入到容器顶部时，浏览器会检测到布局变化。如果 #anchor 元素被选为锚节点，浏览器会自动调整容器的 scrollTop，使得 #anchor 在视口中的位置保持不变。
滚动锚定的工作流程
下面用 Mermaid 流程图展示滚动锚定在浏览器内部的工作流程，以聊天窗口插入新消息为例：
flowchart TD
A[用户滚动到某位置] --> B[浏览器选择锚节点]
B --> C[记录锚节点相对视口的偏移量]
C --> D[新消息插入容器顶部]
D --> E[布局引擎重新计算锚节点位置]
E --> F{锚节点位置是否改变?}
F -- 是 --> G[调整滚动偏移量以补偿位移]
F -- 否 --> H[不调整滚动位置]
G --> I[视口内容保持稳定]
H --> I
这个流程的关键在于，浏览器在布局阶段就完成了锚节点的追踪和补偿，而不是等到绘制或脚本执行。这意味着即使插入操作是由 JavaScript 触发的，滚动调整也会在下一帧渲染前完成，用户感知不到中间状态。
滚动锚定的适用边界与禁用场景
滚动锚定并非在所有情况下都表现良好。它主要解决的是“内容插入导致视口跳动”的问题，但有些场景下它的行为可能不符合预期，甚至需要被禁用。
需要禁用滚动锚定的场景
-
当滚动位置本身是用户主动控制的：例如，用户正在拖动滚动条或使用键盘滚动，此时如果布局发生变化，浏览器可能会干扰用户的滚动操作。不过，规范中通常有机制避免在用户主动滚动时触发锚定，但某些边缘情况仍可能产生冲突。
-
当内容变化发生在视口下方：滚动锚定只关心锚节点（通常位于视口上部）的位置变化。如果新内容插入到视口下方（例如在用户当前阅读位置之后），锚节点位置不变，滚动位置也不会调整，这通常是合理的。但如果开发者期望视口底部的内容也保持稳定，滚动锚定可能帮不上忙。
-
当锚节点被移除或隐藏：如果选中的锚节点在布局变化中被删除或设置为
display: none，浏览器会重新选择锚节点，这可能导致一次额外的跳动。在这种情况下，开发者可能需要手动干预。 -
当元素本身不希望成为锚节点：有些元素（如广告位、动态插入的组件）可能频繁变化，如果它们成为锚节点，会导致滚动位置不断调整。此时可以对这些元素设置
overflow-anchor: none，让浏览器忽略它们。
如何禁用滚动锚定
要禁用整个文档的滚动锚定，可以使用：
* {
overflow-anchor: none;
}或者只针对特定容器：
.chat-container {
overflow-anchor: none;
}MDN 的示例中展示了如何通过 body { overflow-anchor: none; } 来禁用页面级滚动锚定。
与 JavaScript 手动方案的对比
在滚动锚定出现之前，开发者通常使用 JavaScript 来手动维持滚动位置。典型的做法是：在插入内容前记录 scrollTop 和 scrollHeight，插入后重新计算并设置 scrollTop。例如，在聊天窗口中，如果新消息插入到顶部，需要将 scrollTop 增加新消息的高度。
这种方法有几个问题：
- 需要精确测量新内容的高度，而高度可能因图片加载、字体渲染等因素而变化。
- 如果插入操作发生在多个位置（例如同时有内容插入顶部和底部），手动计算很容易出错。
- 需要处理用户滚动与程序滚动的冲突，避免在用户阅读时强制移动滚动条。
滚动锚定由浏览器在布局阶段自动完成，它基于锚节点的位置变化来补偿，不需要开发者测量高度或计算位移。这大大简化了开发工作，并且通常比手动方案更可靠。
下表对比了滚动锚定与手动 JavaScript 方案的差异：
| 维度 | 滚动锚定（overflow-anchor） | 手动 JavaScript 方案 |
|---|---|---|
| 实现方式 | CSS 属性，浏览器自动处理 | 需要监听 DOM 变化并手动调整 scrollTop |
| 对布局变化的感知 | 基于锚节点位置变化，自动补偿 | 需要开发者测量高度并计算位移 |
| 用户滚动冲突 | 浏览器内部处理，通常不会干扰用户主动滚动 | 需要开发者自行判断用户是否在滚动 |
| 代码复杂度 | 无 JavaScript 代码，只需 CSS | 需要编写和维护 JavaScript 逻辑 |
| 性能开销 | 浏览器内部优化，通常开销较小 | 可能引发强制同步布局，如果测量不当会性能下降 |
| 适用场景 | 任何支持滚动锚定的浏览器 | 所有浏览器，但需要处理兼容性和边界情况 |
| 可控性 | 只能通过 auto/none 控制开关，无法精确控制锚节点 | 可以完全控制滚动位置，但需要更多代码 |
需要注意的是，滚动锚定的浏览器支持并非完全一致。MDN 标注该特性“有限可用”，不属于 Baseline，因为它在一些主流浏览器中尚未实现。这意味着在依赖滚动锚定之前，需要检查目标浏览器的兼容性。对于不支持滚动锚定的浏览器，手动方案仍然是必要的。
生产环境中的观察与诊断
在实际项目中，如果你发现滚动锚定没有生效，或者产生了异常跳动，可以从以下几个方面排查：
-
检查元素是否被显式设置为
overflow-anchor: none：有时全局样式或第三方库可能会设置这个属性，导致锚定被意外关闭。 -
确认滚动容器是否正确：滚动锚定作用于滚动容器，如果内容变化发生在一个非滚动容器内，而滚动发生在父级，锚定可能不会按预期工作。
-
观察锚节点的选择：如果页面中有大量动态元素，浏览器可能选择了不合适的锚节点。你可以通过 DevTools 的 Rendering 面板（如果支持）查看滚动锚定的调试信息，或者通过临时设置
overflow-anchor: none来测试是否是锚定问题。 -
注意浏览器差异：不同浏览器对滚动锚定的实现细节可能不同，例如锚节点的选择算法、触发条件等。在跨浏览器测试时，需要特别关注。
总结与适用边界
滚动锚定是浏览器提供的一种自动维持视觉稳定性的机制，它通过选择锚节点并调整滚动位置，有效减少了内容插入导致的视口跳动。overflow-anchor 属性让开发者能够控制这一行为，在需要时关闭它。
这个机制并非万能，它主要适用于内容插入发生在锚节点上方的场景，且要求浏览器支持。在实时聊天、信息流加载等场景中，滚动锚定能显著提升用户体验。但在某些特定场景下，如需要精确控制滚动位置或内容变化频繁且复杂时，开发者可能需要结合手动方案。
理解滚动锚定的工作原理，有助于你在遇到视口跳动问题时做出正确的决策：是依赖浏览器默认行为，还是通过 overflow-anchor: none 关闭它，或者采用 JavaScript 手动处理。关键在于根据实际场景和浏览器支持情况，选择最合适的方案。