正确姿势是：scroll-view需设宽高、white-space: nowrap，子项用inline-block+固定宽；滚动用scrollIntoView或计算offsetLeft居中；点击驱动current，scroll-end校准；禁用scroll-with-animation和可聚焦组件。
uni-app里用scroll-view实现水平滚动导航的正确姿势
直接说结论：不能只靠scroll-x开个开关就完事，得配合white-space: nowrap、display: inline-block和精确的scroll-left控制，否则在iOS和部分安卓WebView里会卡顿、跳项、甚至不滚动。
常见错误是把scroll-view当div用，里面塞一堆view却不设父容器宽度或子项排列方式——结果就是“看着写了滚动，实际点不动、滑不走、回弹错位”。
-
scroll-view必须显式设置width和height（哪怕只是height: 80rpx），不能依赖内容撑开 - 子元素要用
display: inline-block（不是flex），并加white-space: nowrap到父scroll-view上 - 每个分类项建议固定
width（如160rpx），避免不同文字长度导致布局抖动 - 触发滚动时别直接改
scroll-left为像素值，要用scrollIntoView或计算offsetLeft，否则H5端容易失准
点击分类自动居中滚动的实现逻辑（含兼容处理）
闲鱼那种“点哪个，哪个就滑到中间”，不是靠scroll-to，而是靠scroll-into-view + 动态id，但uni-app的scroll-into-view在小程序和H5行为不一致：H5需要先setTimeout等DOM渲染完成，小程序则要确保id唯一且非动态生成。
典型翻车场景：用v-for循环生成id="cate-{{index}}"，但没加:key，导致Vue复用节点后scroll-into-view找不到目标。
- 每个分类
view必须带id，且id值静态可预测（如cate-0、cate-1） - H5端调用
this.$nextTick(() => { this.scrollLeft = ... })比直接赋值更稳 - 想居中，不能只靠
scroll-into-view，得手动算偏移：scrollLeft = target.offsetLeft - (containerWidth - itemWidth) / 2 - 安卓低端机上频繁滚动可能丢帧，建议加
throttle节流，300ms内最多触发一次
tab高亮同步与current状态管理的坑
很多人把current绑定到scroll-view的scroll-left，然后监听scroll事件反推当前项——这在快速滑动时极易误判，尤其列表项宽度不均或有padding时。
真正靠谱的方式是：只响应点击，滑动仅作视觉反馈；高亮状态完全由data.current驱动，滑动结束再用scroll-end事件校准一次（仅兜底）。
- 不要在
scroll中实时计算当前项，性能差还不准；scroll-end才是唯一可信时机 -
current变量必须是Number类型，别传字符串，否则v-if判断会失效 - 高亮样式别用
border-bottom（安卓下常模糊），改用box-shadow: 0 -4rpx 0 #ff6700更清晰 - 如果分类过多（>15个），建议做懒加载：只渲染可视区域前后各2个，其余用占位
view
真机调试时iOS滚动卡顿的三个硬解法
iOS微信/支付宝小程序里scroll-view水平滚动卡，90%是因为开启了scroll-with-animation或者用了transform动画干扰了原生滚动线程。
别信“加will-change: scroll-position就行”，uni-app里这个CSS根本不起作用；真正有效的只有三条：
- 关掉
scroll-with-animation，所有滚动用scroll-left赋值+scrollIntoView代替 - 整个
scroll-view外层加style="overflow: hidden;"，防止父容器截断滚动事件 - 分类项内部禁用
input、textarea、picker等可聚焦组件，iOS会强制切输入法上下文导致卡顿
复杂点在于：滑动惯性、回弹、边界吸附这些体验细节，uni-app没暴露底层API，只能靠反复测scroll-left变化速率+手写缓动函数模拟，这部分没标准解法，得按机型微调。
