overscroll-behavior-y: contain不是开启弹性滚动的开关，而是截断回弹传播路径的策略；其失效主因是容器未设overflow-y:auto/scroll、作用于根元素、iOS嵌套sticky静默失效或旧WebView不支持。
移动端弹性滚动（即滑动到边界时的“回弹”效果）不能单靠一个 CSS 属性开启，overscroll-behavior-y: contain 只能拦截回弹传递，而真正的弹性是否出现、是否顺滑，取决于滚动容器是否被系统识别为原生可滚动区域——这在 iOS 上尤其敏感。
为什么 overscroll-behavior-y: contain 看似没反应
它根本不是“开启弹性”的开关，而是“截断弹性传播路径”的策略。常见失效原因包括：
- 容器没设
overflow-y: auto或scroll—— 仅靠内容溢出不会创建滚动上下文，overscroll-behavior直接不生效 - 写在
html或body上 —— 它对根元素无效，必须作用于子级滚动容器（如.modal-content、.chat-list） - iOS Safari 嵌套了
position: sticky元素 —— iOS 17.4 仍存在静默失效，回弹会穿透到父层 - Android WebView（如微信 X5）版本过旧 —— 可能完全忽略该声明，不报错也不执行
iOS 上真正触发弹性滚动的关键条件
现代 iOS（≥16.4）默认启用弹性，但前提是滚动容器满足原生滚动引擎识别条件：
- 必须有明确高度约束：
height、max-height或100dvh（别用100vh，地址栏收起时会塌缩） - 避免祖先元素含
transform、opacity、filter—— WebKit 会打断滚动线程，导致惯性丢失、回弹变“钉住” - 删掉所有残留的
-webkit-overflow-scrolling: touch—— Chrome 63+ 和 Safari 15.4+ 已废弃，加了反而强制降级旧引擎，惯性失效 - 确保滚动容器内没有
touchmove全局监听器（尤其带preventDefault()的），否则会阻塞原生滚动链路
如何验证弹性是否真被系统接管
不能只看视觉反馈，要确认底层机制是否就位：
立即学习“前端免费学习笔记（深入）”；
- 打开 Safari 开发者工具 → Elements → 选中滚动容器 → 检查 Computed Styles 中
overflow-y是否为auto，且height计算值非auto - 手指快速甩动后松手：若内容继续滑行（惯性），再触顶/底时有明显拉伸+回弹动画，说明系统级滚动已激活
- 若一松手立刻停住，或触顶时背景页跟着抖一下 —— 不是
overscroll-behavior没用，是滚动上下文本身没建起来 - 用
document.scrollingElement?.scrollTop在滚动中读取 —— 若数值变化不连续（跳变），说明主线程被阻塞，原生滚动已被 JS 干扰
真正容易被忽略的是：弹性滚动体验由滚动上下文建立 + 系统渲染策略 + 事件链路完整性共同决定。overscroll-behavior-y 只负责其中最后一环的传播控制，漏掉前面任意一环，它就变成摆设。
