overscroll-behavior通过声明式控制滚动边界而非拦截事件来阻断滚动链，其根本原因是告诉浏览器该元素的滚动边界即为其内容盒，到此为止不再向上查找可滚动祖先。
overscroll-behavior 能阻止滚动链向上传递，根本原因不是它“拦截事件”，而是它告诉浏览器：这个元素的滚动边界就是它的内容盒（content box），到此为止，别再找父级了。
滚动链的本质是浏览器的默认滚动传播策略
当用户在可滚动容器内滑动到底部，继续拖拽时，浏览器会按 DOM 层级向上查找最近的可滚动祖先（比如 body 或 html），并把剩余滚动量“移交”过去 —— 这就是滚动链。它不依赖 JavaScript 事件流，也不走 event.stopPropagation()，所以用 touchmove + preventDefault() 很难 100% 拦住（尤其 iOS 快速滚动、惯性、鼠标滚轮混合场景）。
overscroll-behavior 是 CSS 渲染层的声明式控制，直接参与浏览器滚动行为的决策逻辑，绕开了事件监听的种种兼容性陷阱。
overscroll-behavior: contain vs none：关键区别在“本地反馈”
两者都阻断向上传播，但对用户当前滚动容器的本地表现处理不同：
-
contain：允许该元素自身保留平台原生的边界效果，比如 iOS 的橡皮筋回弹、Android 的 overscroll glow；适合需要视觉反馈但又不想影响背景页的弹窗或侧边栏 -
none：不仅切断传播，还完全禁用本地边界效果 —— 滚到顶/底就“硬停”，无回弹、无发光；适合需要严格边界控制的场景（如自定义下拉刷新容器，否则会和原生 pull-to-refresh 冲突）
注意：overscroll-behavior 是 shorthand，overscroll-behavior-y 和 overscroll-behavior-x 可以单独设置，比如只禁纵向传播而保留横向溢出滚动（常见于横向滑动卡片组）。
必须作用在“实际可滚动的元素”上才生效
很多人加了 overscroll-behavior: contain 却没效果，是因为目标元素本身不可滚动 —— 浏览器根本不触发 overscroll 行为判断。
确认以下三点：
- 该元素设置了
overflow-y: auto或scroll（且内容高度 > 元素高度） - 没有被
overflow: hidden或pointer-events: none干扰 - 不是通过
transform或position: fixed间接创建的滚动上下文（某些旧版 Safari 对 fixed 容器支持不稳，建议显式加overscroll-behavior）
典型误用：body 上设 overscroll-behavior: contain 想防弹窗穿透，结果无效 —— 因为弹窗内容区域才是实际滚动源，控制点必须落在那个 div.scrollable 上。
iOS 下拉刷新与 overscroll-behavior 的隐式冲突
在 iOS Safari 中，overscroll-behavior: contain 应用于 body 或 html 会同时禁用原生 pull-to-refresh，这是副作用而非 bug —— 因为下拉刷新本质上就是 overscroll 触发的系统级行为。
如果你要自己实现下拉刷新：
- 用
overscroll-behavior-y: none在刷新容器上，彻底关闭系统行为 - 避免在
body上设none，否则整个页面失去顶部回弹反馈，体验生硬 - 注意：iOS 16+ 对
overscroll-behavior支持已稳定，但部分微信内置 WebView（X5 内核）仍忽略该属性，需 fallback 到touchmove+passive: false
真正容易被忽略的是：这个属性不继承，也不受 display: contents 或 flex/grid 容器影响，它只对“自身具备滚动能力”的元素起效 —— 所以检查 computed styles 里的 overflow 和 overscroll-behavior 是否同时存在，比看 DOM 结构更可靠。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
