单纯加 -webkit-overflow-scrolling: touch 不一定能解决卡顿，它只是申请原生滚动资格的必要条件，需配合 overflow-y: scroll、显式高度及避免干扰合成层的 css 才可能生效。
直接结论：单纯加 -webkit-overflow-scrolling: touch 不一定能解决卡顿，它只是“申请原生滚动资格”的必要条件，不是万能开关。真正起效的前提是容器满足硬件加速滚动的所有硬性条件，否则这行 CSS 会被 WebKit 忽略。
为什么加了 -webkit-overflow-scrolling: touch 还是卡
这个属性本质是向 WebKit 提交一份“合成层申请”，但系统会当场审核：是否具备原生滚动资格。常见被拒原因包括：
- 父级有
overflow: hidden或position: fixed，直接阻断滚动事件冒泡路径 - 滚动容器没设
height或max-height，WebKit 判定“内容没溢出，无需滚动” - 容器或其子元素用了
transform、filter、will-change: opacity等导致图层分离失败的属性 - 同时存在多个嵌套滚动容器（比如
scroll-view套div），触发滚动权冲突
必须配对的 CSS 基础配置
只写 -webkit-overflow-scrolling: touch 是无效的。它必须和以下三项共存才可能生效：
-
overflow-y: scroll（或auto），不能是visible - 显式高度控制：用
height、max-height或vh单位（如height: 60vh），禁用min-height或依赖内容撑高 - 避免干扰合成层：移除父级的
overflow: hidden；慎用position: absolute/fixed包裹滚动区
典型可用写法：
.scroll-area {
height: 500px;
overflow-y: scroll;
-webkit-overflow-scrolling: touch;
}
@touchmove 中 preventDefault() 是隐形杀手
很多开发者在监听滑动方向时，习惯性在 @touchmove 里无条件调 e.preventDefault()，这等于主动放弃 iOS 原生滚动管线——后续所有惯性、回弹、弹性都失效，JS 只能靠 scrollTop 一帧帧硬推，必然卡顿。
- 仅当你**真要接管滚动逻辑**（如拖拽排序、自定义抛物线动画）时，才调
preventDefault() - 如果只是检测滑动方向或距离，用
Math.abs(deltaY) > 5判断后，**不调preventDefault()**，让系统继续滚动 - 检查第三方组件（如
swiper、uni-app的scroll-view）是否内部已调用，重复调用会导致滚动失灵
容易被忽略的兼容性细节
iOS 16+ 对 -webkit-overflow-scrolling 的审核更严格，且部分场景下即使生效也会伴随新问题：
- 输入框聚焦时滚动位置丢失：需监听
focusin事件手动保存scrollTop，失焦后恢复 - z-index 层级错乱：给滚动容器加
transform: translateZ(0)或isolation: isolate强制创建新图层 - 橡皮筋回弹异常：加
overscroll-behavior: contain阻止穿透到父容器 - 滚动条干扰体验：用
::-webkit-scrollbar { display: none; }隐藏（仅限 iOS Safari）
最麻烦的一点是：这个属性在 iOS 16.4 后已被标记为“deprecated”，虽仍可用，但未来版本可能彻底移除。现在就要开始评估用 scroll-driven animations 或原生 scroll() API 替代的可行性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
