overscroll-behavior 不提升滚动性能，仅控制滚动边界行为；误用会导致列表卡顿或丢失回弹，它不解决帧率卡顿、重排重绘或合成层问题，真正影响流畅度的是硬件加速、虚拟滚动和事件处理方式。
直接说结论：overscroll-behavior 本身不提升滚动性能，它只控制滚动边界行为；用错地方反而会让列表“卡住”或丢失回弹反馈，别把它当 scroll performance 优化手段。
overscroll-behavior 不是 scroll performance 的解决方案
很多人看到“优化滚动”，第一反应是加 overscroll-behavior: contain，结果发现列表滑得更涩、惯性变弱、甚至 iOS 上触底没弹性了——这是因为混淆了两个问题：滚动链（scroll chaining） 和 滚动帧率/卡顿（jank）。
overscroll-behavior 只干预“滚动到边界后要不要传给父元素”，它不改变 scroll event 触发频率、不减少重排重绘、也不影响合成层创建。真正影响长列表滑动流畅度的是：
-
will-change: transform或transform: translateZ(0)是否触发硬件加速 - 是否用了虚拟滚动（virtualized list），而非渲染全部 DOM 节点
- 是否在
scroll或touchmove里做了同步计算（比如实时计算高度、调用getBoundingClientRect()） -
overflow-y: auto容器是否被position: fixed或transform破坏滚动上下文
它真正该用在哪？解决滚动穿透，不是卡顿
当你遇到这些情况时，overscroll-behavior: contain 才是正解：
- 弹窗（
.modal）里有个固定高度的评论列表，用户滑到底部继续拖，背后页面跟着滚 - 侧边栏菜单（
.sidebar）设置了overflow-y: auto，但滑到顶/底时主内容区也动了 - 聊天窗口（
.chat-messages）内嵌在position: relative的容器中，滚动触顶后触发了页面刷新（pull-to-refresh）
关键前提是：该元素必须是真正的滚动容器，即满足以下任一条件：
-
overflow-y: auto或scroll（不能是hidden） - 内容高度超出容器高度（否则没有滚动边界可触发）
- 没有被
touch-action: none全局禁用触摸行为
常见失效原因和绕过方式
写了 overscroll-behavior: contain 却没效果？大概率踩了这几个坑：
- 父元素（如
body）设置了overflow: hidden，但没锁住scrollY—— iOS Safari 会忽略子元素的contain，继续把 overscroll 传给 viewport - 容器用了
display: flex+flex-direction: column，但没设明确高度（如height: 100vh），导致浏览器无法判断滚动边界 - 在 iOS 17.4 之前，嵌套了
position: sticky的元素会破坏overscroll-behavior生效（已知 bug，无 CSS 修复方案） - 同时写了
-webkit-overflow-scrolling: touch—— 这个废弃属性会静默覆盖overscroll-behavior，Safari 只认前者
兜底建议：如果必须兼容老 iOS 或 WebView，不要只靠 CSS。检测到 overscroll-behavior 不生效时，用 JS 监听 touchmove 并动态加 body { position: fixed; top: -${window.scrollY}px } 锁定视口。
值选 contain 还是 none？看用户预期
contain 是安全选择：保留弹性回弹（bounce），只切断滚动链；none 会干掉所有 overscroll 行为，包括 iOS 拉到顶时的发光效果、下拉刷新提示，甚至某些 Android 的滚动惯性衰减。
用 none 的真实场景极少，仅限：
- 轮播图容器（
.carousel）需完全禁用垂直 overscroll，防止误触背景滚动 - 游戏 UI 层（
.game-overlay）要求零干扰，连 bounce 都算 UX 噪音 - 配合自定义 pull-to-refresh 实现，必须彻底屏蔽原生下拉行为
多数业务场景下，overscroll-behavior: contain 就够了。别为了“看起来更干净”而牺牲用户对边界的感知——那不是优化，是删功能。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
