iOS滑动卡顿主因是scroll-view误用、CSS重排或@touchmove中滥用preventDefault()；真正生效的是-webkit-overflow-scrolling: touch配合原生滚动资格，而非单纯“开启惯性滚动”。
直接说结论：iOS滑动卡顿，90%不是“没开惯性滚动”，而是scroll-view被误用、CSS触发重排、或@touchmove事件里调了preventDefault()又没配对处理。所谓“开启惯性滚动”只是个表象，真正起作用的是-webkit-overflow-scrolling: touch是否生效 + 滚动容器是否具备原生滚动资格。
scroll-view在iOS上为什么越用越卡
uni-app官方明确不推荐用scroll-view做长列表——它本质是WebView内模拟滚动，iOS WebView对频繁scrollTop变更和样式重绘极其敏感。一旦列表项超过50条、或每个item含图片+阴影+圆角，主线程立刻吃紧。
- 避免把整个页面包进
- 如果必须用
scroll-view，务必设固定height（如height: 100vh），不能靠内容撑高 - 禁用
scroll-with-animation，动画会强制同步渲染，放大掉帧 - 横向滚动时，给子容器加
white-space: nowrap和display: inline-block，比flex更稳
-webkit-overflow-scrolling: touch到底怎么写才生效
这个CSS属性不是“开关”，而是“申请书”：只有当元素满足原生滚动条件时，WebKit才批准它走硬件加速通道。常见失效场景：
- 父级有
overflow: hidden或position: fixed遮挡，直接拒批 - 滚动容器没有显式
height或max-height，WebKit判定“无需滚动” - 用了
transform或filter等会让元素脱离文档流的属性，合成层创建失败 - 在
@touchmove中无条件调e.preventDefault()，等于告诉系统“别管我，我自己滚”，结果自己又没能力滚
正确写法示例：
.list-container {
height: 500px;
overflow-y: scroll;
-webkit-overflow-scrolling: touch;
}
@touchmove事件里preventDefault()的坑
很多教程教你在@touchmove里直接e.preventDefault()来“阻止默认行为”，但在iOS上，这相当于拔掉滚动引擎的油管——后续所有惯性、回弹、弹性都失效，只能靠JS一帧帧算位置，必然卡顿。
- 只在你**确实要接管滚动逻辑**时才调
preventDefault()（比如实现拖拽排序） - 若只是监听滑动方向，用
Math.abs(deltaY) > 5判断阈值后，**不调preventDefault()**，让系统继续滚动 - 如果父容器也需要滚动（比如嵌套
scroll-view），确保事件冒泡不被.stop截断 - 检查第三方组件（如
swiper）是否内部已调preventDefault()，再叠加会导致冲突
真正有效的“惯性滚动”替代方案
与其折腾scroll-view和CSS，不如换路径：用页面级滚动（即靠内容撑出body滚动条）+ 吸顶/吸底布局。这是iOS最信任的滚动模式，天然支持惯性、回弹、快速滑动。
- 在
pages.json中关闭原生导航栏："navigationStyle": "custom"，避免原生栏干扰 - 顶部tab用
position: sticky或z-index吸顶，主体内容留出足够高度 - 长列表直接用
v-for渲染在页面流中，不要套任何滚动容器 - 需要下拉刷新？用
onPullDownRefresh生命周期，它绑定的是页面级滚动事件，iOS原生支持
复杂点在于吸顶区域与滚动区域的边界计算——这里最容易漏掉padding-top补偿，导致内容被遮挡。iOS不会自动帮你修正，得手动测真机。
