移动端CSS设置overflow: scroll但无惯性滚动，需添加-webkit-overflow-scrolling: touch属性。

在移动端尤其是iOS Safari中，为实现流畅的惯性滚动效果，仅设置`overflow: scroll`远远不够，必须保留已被废弃但至今仍不可替代的`-webkit-overflow-scrolling: touch`属性——它仍是iOS上激活原生滚动物理特性的唯一开关，缺失会导致拖动后立即停止、无回弹、无法甩动等体验断层；而真正影响滚动生效的深层原因往往在于布局陷阱（如高度未明确、父级`overflow: hidden`拦截事件）或合成层滥用引发的卡顿，因此关键不在于盲目加前缀，而在于构建“可预测的渲染上下文”：确保滚动容器尺寸可控、事件链路畅通、避免与`position: fixed`或`transform`等触发冲突的样式共存——掌握这些，才能让惯性滚动既可靠又高效。

因为 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 私有前缀只是最后一道闸门，闸门之前，布局和事件流已经决定它开不开。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~