scroll-view 的 bindscroll 代替 onpagescroll 监听滚动，因 onpagescroll 仅响应页面级滚动；需用 fixed + 占位元素实现稳定吸顶，避免 sticky 或 transform；平滑滚动应手动计算偏移并减去 tab 高度；必须节流 bindscroll 以防止卡顿，推荐 requestanimationframe 节流。
scroll-view 的 bindscroll 代替 onPageScroll 监听滚动
商品详情页几乎都用 scroll-view 包裹内容，onPageScroll 在这种结构下根本不会触发——尤其在微信小程序和 iOS App 端，它只响应页面级滚动（即 page 根节点的滚动），而 scroll-view 是独立滚动容器。直接监听 bindscroll 才是正解。
常见错误：把 event.detail.scrollTop 拿来直接比大小，结果吸顶时机飘忽不定。原因有二：一是浮点误差（比如 199.9999999 被误判为 scrollTop 可能为 undefined 或 0，导致判断逻辑错乱。
- 用
Math.round(scrollTop)做整数对齐，比如Math.round(scrollTop) >= 200 - 在
mounted或onReady里主动初始化滚动位置：this.$nextTick(() => this.$refs.scrollView?.scrollTo({scrollTop: 0})) - 给
scroll-view加scroll-y="true"和ref="scrollView"，确保 ref 可访问
用 fixed + 占位元素实现稳定吸顶，别碰 sticky
position: sticky 在 H5 上看着还行，但在微信小程序、App（尤其是 iOS）里表现极差：要么完全不吸顶，要么吸顶后错位、跳动、甚至卡死。uni-app 官方文档也明确不建议在复杂滚动容器中使用 sticky。
老老实实用 position: fixed + 动态 class 控制显示状态，但必须处理脱离文档流带来的“抖动”问题——Tab 固定后，下面的内容会突然上移，用户体验极差。
- 给 Tab 原位置加一个同高度的占位
<view class="tab-placeholder" :style="{ height: tabHeight + 'px' }"></view> - Tab 元素加 class：
:class="{ 'tab-fixed': isSticky }"，CSS 中写.tab-fixed { position: fixed; top: 0; z-index: 999; width: 100%; } -
tabHeight必须是真实像素值（px），不能用upx；若需响应式，用uni.upx2px(80)转换后存入 data - 绝对不要用
transform: translateY()模拟吸顶——iOS WebView 对 transform 内滚动支持极不稳定，极易失焦或滚动失效
点击 Tab 平滑滚动到对应区块，避免 scrollIntoView 失效
scroll-view 的 scroll-into-view 属性在长列表或动态渲染内容中经常失效：跳空、跳到顶部、或直接没反应。根本原因是它依赖元素 id 渲染完成且可被原生识别，而 uni-app 中 DOM 节点生成时机和查询机制与原生不同。
可靠做法是手动计算目标节点偏移量，再调用 scrollTo。关键点在于：偏移量必须减去吸顶 Tab 的高度，否则目标内容会被遮挡。
- 用
uni.createSelectorQuery().in(this).select('#params')获取目标元素位置 - 包裹在
this.$nextTick里确保 DOM 已更新 -
scrollTop设为data.top - this.tabHeight，其中tabHeight是你实际设置的吸顶栏高度（如 44） - 点击 Tab 后立刻置
isScrolling = true，防止快速连点触发多次滚动；在bindscroll回调末尾加setTimeout(() => this.isScrolling = false, 300)
节流滚动监听，防 setData 飙升卡顿
每次 bindscroll 触发都执行 setData（比如更新 isSticky 或当前高亮 tab），在低端安卓机或长页面上会明显卡顿。这不是 JS 性能问题，而是 uni-app 的 setData 通信层在高频调用下堆积导致的渲染延迟。
节流不是可选项，是必做项。重点不是“要不要节流”，而是“节流阈值设多少”和“节流逻辑是否覆盖所有端”。
- 推荐 16ms ~ 32ms 节流窗口（约 30~60fps），用
let ticking = false+requestAnimationFrame最稳 - 别用
setTimeout模拟节流——在 iOS 微信里 setTimeout 延迟可能严重漂移 - 节流函数内只做必要判断（如
Math.round(scrollTop) >= threshold），高亮切换逻辑另起一个低频 watch 或 computed - 真机多端测试必须做：iOS 微信、Android 微信、App（iOS/Android）、H5，各端滚动频率和事件触发时机差异极大
吸顶 Tab 看似简单，真正上线前最容易翻车的不是逻辑，而是不同端对 scroll-view 行为的理解偏差——比如 iOS App 里 scrollTop 初始值可能是负数，微信小程序里 scrollTo 的 duration 参数完全无效。这些细节不靠真机反复测，光看文档或模拟器根本发现不了。
