取消iOS页面滑动回弹需分端处理：App端用pages.json配置bounce，H5端需CSS+JS+容器约束组合，小程序端默认无回弹；各端机制不同，不可跨端复用同一方案。
直接取消 iOS 的页面滑动回弹，不能只靠一个配置或一行 CSS。不同端（App、H5、小程序）机制完全不同，同一套代码在 H5 里加 overscroll-behavior: none 有效，在 App 端却完全不生效；而在 App 端起效的 bounce: "none"，H5 里又会被 Safari 忽略。必须按端区分处理。
App 端（iOS/Android 原生 WebView）用 pages.json 配置 bounce
这是最稳定、最优先的做法。uni-app 的 App 端底层是 WKWebView（iOS）或系统 WebView（Android），回弹由原生容器控制，JS/CSS 无法干预。
-
bounce: "none"必须写在pages.json的页面级style.app-plus或全局globalStyle.app-plus下，写在 CSS 或 JS 里无效 - 支持细粒度控制：
{"top": "none", "bottom": "none"}可单独禁用顶部或底部回弹 - 注意：该配置仅对 App 端生效，H5 和小程序中完全被忽略，不要指望它跨端
- 如果配置后仍回弹，检查是否启用了
pullToRefresh—— 下拉刷新和 bounce 是互斥的，开启刷新会强制恢复 bounce 行为
H5 端（iOS Safari）必须组合 CSS + JS + 容器约束
iOS Safari 的回弹本质是 body 的 overscroll 行为，单靠 overflow: hidden 不够，overscroll-behavior: none 也需严格条件才能生效。
-
body和html都要设overflow: hidden; height: 100%;，缺一不可，否则 Safari 会降级为默认行为 -
overscroll-behavior: none必须作用于body或html，写在子容器上（比如.content）完全无效 - 若页面内有
<scroll-view>，它必须带固定高度（如height: 600rpx或height: calc(100vh - 100rpx)），不能用flex: 1或纯100vh（Safari 对vh计算不准） - 真机调试前务必关闭 HBuilderX 的「调试基础库」——它会注入冲突的 touch 监听器，导致回弹更顽固
微信小程序端基本不用处理
微信小程序的 WebView（iOS 上是 WKWebView）默认不启用页面级 bounce，只要没手动开启下拉刷新（enablePullDownRefresh: true），就不会出现顶部回弹空白。
- 如果页面内容不足一屏，用户下拉只会看到“下拉刷新”的提示框（前提是开启了刷新），不会拉出灰色空白区
- 若你发现有异常回弹，大概率是用了
<scroll-view>且未设scroll-y或高度太小，导致内部滚动失效，事件透传到了页面级——这时应检查scroll-view的高度和scroll-y是否正确启用 - 小程序中
bounce配置在pages.json中无意义，不要加
scroll-view 组件内回弹失效或卡顿的常见原因
不是所有“回弹”都来自页面根容器，很多其实是 <scroll-view> 自身行为异常，尤其在嵌套或定位布局中。
-
bounces="false"在 H5 端完全无效，别依赖它；App 端有效，但只对原生滚动层起作用 - 避免给
<scroll-view>外层加position: fixed或absolute—— 这会切断滚动上下文，导致内部滚动权被父级劫持 - 不要在
<scroll-view>的父<view>上写@touchmove.prevent，这会阻止事件冒泡，scroll-view根本收不到 touch 数据 - 判断是否真可滚动：用
getBoundingClientRect()检查scroll-view内容实际高度是否 > 容器高度，差 1px 就可能触发回弹
最容易被忽略的是：H5 端的 overscroll-behavior 在 iOS 13 以下不支持，App 端的 bounce 配置在 nvue 页面里需要配合 renderer: "native" 才能完全生效，而这些细节往往只在真机连 USB 调试时才暴露出来。
