必须保留 -webkit-overflow-scrolling: touch，因 iOS Safari（含17.4）仍依赖它启用滚动惯性，且无现代替代方案；不加则拖完即停、无回弹、无法甩动。
因为 iOS Safari 默认只对 body 或根滚动容器启用原生惯性，普通元素加了 overflow: scroll 只是“能滚”，不是“会惯性地滚”——而 -webkit-overflow-scrolling: touch 是 iOS 上唯一能激活该行为的开关（尽管它已被废弃，但目前仍必需）。
为什么 -webkit-overflow-scrolling: touch 现在还不能删
iOS Safari（包括 iOS 17 和 Safari 17.4）仍未完全移除对该属性的支持，且没有等效的现代替代方案。不加它，90% 的自定义滚动容器在 iOS 上都会：拖完即停、无回弹、无法甩动、边缘卡死。
- Android Chrome 完全忽略它，靠系统 WebView 自行处理惯性，加了也无效但无害
- iOS 15.4+ 开始标记为废弃，但 WebKit 并未真正移除逻辑——只是不再保证行为稳定
- 加了之后若滚动异常（如 fixed 元素错位、内容闪烁），大概率是触发了合成层冲突，不是属性本身失效
overflow-y: scroll 没惯性的常见布局陷阱
即使写了 -webkit-overflow-scrolling: touch，也常因父级或自身尺寸失控导致失效：
- 容器高度为
height: auto或依赖 flex 基线（比如父容器没设min-height: 0），滚动区域没有“边界”，overflow形同虚设 - 父容器设置了
overflow: hidden，直接截断滚动事件流，子元素再怎么配也滚不动 - 用了
position: absolute+top: 0模拟滚动，绕过了原生滚动机制，-webkit-overflow-scrolling完全不生效 - 在微信内置浏览器或某些安卓 WebView 中，
100vh高度会因地址栏收起跳变，建议改用100dvh（iOS 16.4+ 支持）或 JS 动态计算
加了 -webkit-overflow-scrolling 却更卡？这是典型合成层滥用
该属性会强制创建独立合成层，新版 WebKit 对这类手动分层调度已重构，容易引发：
立即学习“前端免费学习笔记（深入）”；
- 层爆炸（layer explosion）：子元素频繁重绘，CPU 占用飙升
-
position: fixed元素脱离 viewport 坐标系，“悬浮错位”——建议改用position: sticky - 与
transform: translateZ(0)冲突，触发双重合成，掉帧明显 - 不要在长列表或高频更新区域滥用；仅在明确需要惯性的滚动容器上设置
现在该不该用 JavaScript 模拟惯性滚动
除非你有不可妥协的定制需求（比如滚动中精确控制视差、交互动画或 canvas 渲染），否则不要。
- iScroll / better-scroll / smooth-scrollbar 等库在 iOS 上必然比原生慢半拍，且无法响应系统级物理曲线
- 它们会干扰双击放大、光标定位、页面缩放等原生能力
- 若必须接管，至少用
{ passive: true }监听touchmove，配合getBoundingClientRect()计算位置，而非全量接管scrollTop -
scrollTo({ behavior: 'smooth' })在 iOS 上只是缓动动画，不是惯性滚动，别混淆
真正关键的不是加哪个属性，而是滚动容器是否具备「可预测的渲染上下文」：明确高度、不拦截 touch 事件、不破坏滚动链路。WebKit 私有前缀只是最后一道闸门，闸门之前，布局和事件流已经决定它开不开。
