CSS overscroll-behavior 怎样阻止嵌套滚动传递

弹窗、侧栏或聊天面板滚到顶端/底端后，页面背景又跟着移动，通常不是滚动事件失控，而是浏览器默认允许滚动从内层容器继续传给祖先容器。这个行为叫 scroll chaining。处理这类问题，优先给真正的滚动容器设置 overscroll-behavior: contain；如果连边界回弹也不想要，再改用 none。

记住三个判断：auto 保持默认传递，contain 截断传递但保留回弹，none 同时截断传递和回弹。属性只对滚动容器生效，不能替代 overflow 或固定高度设置。

先判断是谁在接收滚动

一个嵌套滚动场景至少有两层：内部的列表、弹窗或侧栏，以及外层页面。当内层有可滚动溢出时，手势先作用于内层；到达内层边界后，如果仍继续滚动，默认行为可能把剩余滚动交给外层页面。移动端还可能出现回弹或类似下拉刷新的效果。

因此第一步不是马上写 CSS，而是确认内层元素确实是滚动容器：它需要有可滚动内容，并配合 overflow: auto 或 overflow: scroll。如果元素没有高度约束，内容把父级撑开，滚动根本没有发生在它身上，设置 overscroll-behavior 也不会得到预期结果。

用 contain 截断滚动串联

侧栏、聊天记录和弹窗正文最常见的需求是：内部可以正常滚动，但滚到边界后不让背景页面接着移动。此时使用 contain，它只改变边界处的传递策略，不会把内部滚动禁掉。

.drawer__body {
  /* 让内容在侧栏内部滚动，而不是把页面撑高 */
  max-block-size: 70vh;
  overflow: auto;
  /* 到达上下边界后不把滚动继续交给页面 */
  overscroll-behavior: contain;
}

如果页面还会在弹窗打开时被背景滚动，可以把规则放在实际承载滚动内容的面板上；不要只写在遮罩层上。对没有滚动溢出的元素，浏览器会把它视为处于滚动边界，规则仍可能影响祖先滚动，所以选择器范围要尽量贴近弹窗的滚动区域。

contain 和 none 到底差在哪里

overscroll-behavior 是 overscroll-behavior-x 与 overscroll-behavior-y 的简写，可以写一个值，也可以分别指定横向和纵向。四个常用值的差异如下：

如果只想控制纵向聊天列表，可以避免影响横向手势：

.chat__messages {
  /* 只切断纵向滚动串联，横向保留默认行为 */
  overscroll-behavior-y: contain;
}

反过来，横向轮播或表格可以使用 overscroll-behavior-x。轴向属性比一刀切的简写更容易和横向拖动、触摸手势共存。

仍然不生效时按边界排查

1. 检查滚动容器。确认目标节点有固定或最大尺寸、内容确实溢出，并且 overflow 没有被其他选择器覆盖。
2. 检查规则位置。把属性放在接收滚轮/触摸滚动的内层容器，而不是只放在父级包装、遮罩或按钮上。
3. 检查 iframe 边界。iframe 本身不是普通滚动容器；如果要控制 iframe 文档内部的串联，需要在 iframe 文档自己的 html 和 body 上设置。
4. 检查兼容性。MDN 将该属性标记为 Limited availability，正式产品要结合目标浏览器范围准备降级体验；不要把它当成 JavaScript 事件拦截的完全替代品。

排查时可以先临时给目标元素加一个明显边框，确认滚动条和滚动内容都属于同一个节点，再决定使用 contain 还是 none。如果需求只是避免背景滚动，通常从 contain 开始更稳妥。

常见问题

设置 contain 后为什么内层还是不能滚动？

contain 只处理到达边界之后的传递，不会创建滚动区域。先检查容器是否有可用高度、内容是否溢出，以及 overflow 是否设置为 auto 或 scroll。

contain 和 none 应该怎么选？

希望用户在边界处仍能感知滚动到头，选 contain；希望连回弹反馈也去掉，才选 none。移动端交互通常先选择前者，再根据实际体验收紧。

总结来说，嵌套滚动问题要先确认滚动容器，再用 overscroll-behavior 决定边界行为：contain 是阻止滚动传递的常用起点，none 是更强的边界控制，轴向属性则用于保留另一方向的手势体验。