iOS上scroll-view需二次滑动才动，根本原因是事件阻塞与回弹干扰；必须在pages.json设disableScroll:true、scroll-view加bounces="false"、启用enhanced并锁定高度，配合图片懒加载、稳定key、禁用冗余样式及真机调试。
scroll-view 在 iOS 上二次滑动才动，根本原因是事件阻塞 + 回弹干扰
这不是 bug，是 iOS WKWebView 对嵌套滚动的保守处理：父容器没明确禁用回弹、touch 事件被意外阻止、或页面级滚动没关，都会让系统“犹豫”是否该把滑动手势交给 scroll-view。结果就是第一次滑只是触发了页面级回弹，第二次才真正滚动内容。
-
disableScroll: true必须加在pages.json对应页面的style里，否则页面自带滚动会和 scroll-view 抢事件 -
bounces="false"要写在 scroll-view 标签上，仅靠 CSS 的-webkit-overflow-scrolling: touch不足以禁用回弹 - 别在 scroll-view 外层或 body 上绑
@touchmove.prevent，哪怕只有一处，整个滑动链就断了 - 真机测试前务必关闭 HBuilderX 的「启用调试基础库」选项——它会在 iOS 上注入额外事件监听，放大卡顿
enhanced=true 真有用，但必须配合高度锁定
uni-app 的 enhanced 属性不是锦上添花，而是 iOS 滚动性能的关键开关：它启用原生滚动代理，绕过部分 WebView 渲染瓶颈。但它有个硬前提——scroll-view 必须有确定高度，否则增强模式自动降级，退化成普通 div 滚动。
- 高度不能靠
100%或flex: 1模糊计算，得用vh、px或动态:style="{ height: scrollHeight + 'px' }" - 如果内容高度动态变化（比如加载更多后），记得调用
this.$nextTick(() => this.$refs.scrollView?.scrollTo({ scrollTop: 0 }))强制刷新滚动上下文 - 在低端 iPhone（如 SE 第二代）上，
enhanced+bounces=false组合比单纯加will-change: transform有效 3 倍以上
图片和列表项是隐藏的帧率杀手
滑动卡顿经常不来自滚动逻辑本身，而来自每一帧都要重绘的 DOM 节点：未压缩的大图、无 key 的 v-for、带阴影/渐变的 item 容器，都会让 iOS WebKit 在 60fps 下挣扎。
- 所有
lazy-load，且 src 使用 CDN 压缩后的 WebP（iOS 14+ 原生支持） - v-for 列表中每个 item 的
key必须是稳定唯一值，禁止用:key="index" - 避免在 scroll-view 内使用
box-shadow、border-radius超过 2px，改用transform: translateZ(0)触发 GPU 加速 - 长列表优先换用
uv-list或 nvue 的list，webview 下的虚拟滚动对 iOS 友好度远高于手动实现
别信模拟器，也别信 H5 预览
iOS 滑动问题在模拟器里几乎不复现，在 H5 端也常表现正常——因为它们用的是不同内核（macOS Safari 和 Chromium）。只有真机 + WKWebView 才暴露真实瓶颈，比如 touchend 延迟 80ms、scroll 事件节流失效、或图片解码抢占主线程。
- 用 Safari 远程调试：连上 iPhone → 开发者菜单 → 选中你的页面 → 时间线里看 FPS 和 JS 主线程占用
- 禁用所有 console.log，尤其在
bindscroll回调里，iOS 下 log 本身就会掉帧 - 如果用了第三方下拉组件（比如 mescroll），先注释掉，确认是原生 scroll-view 问题再深入
实际项目里，最常漏掉的是 pages.json 的 disableScroll 和 scroll-view 的高度锁定——这两项不落实，其他优化全打折扣。
