原生scroll-view横向滚动存在三端兼容性硬伤：iOS不跟手、安卓偶发卡顿、scroll-into-view对异步生成ID支持差；根本原因是底层依赖各端WebView滚动能力，事件触发时机与精度不一致。
uni-app里用scroll-view实现横向滚动导航的硬伤在哪
直接说结论：原生scroll-view在iOS上滚动不跟手、安卓偶发卡顿，且scroll-into-view对动态生成的id支持极差——尤其分类菜单是异步加载时，scroll-into-view大概率失效。
根本原因是uni-app的scroll-view底层依赖各端WebView的原生滚动能力，而微信小程序、App、H5三端的滚动事件触发时机和精度不一致。你看到的“点击没反应”，八成是scroll-into-view执行时目标元素还没渲染完成。
- 必须等
nextTick或$nextTick后再调用scrollIntoView（Vue 2/3写法不同） - 目标元素
id不能含特殊字符或数字开头（如id="1-food"在iOS会失败） - H5端建议改用
scrollLeft手动计算偏移，避开scroll-into-view兼容性黑洞
怎么让点击分类后导航自动居中且不跳
靠scroll-view自带属性做不到平滑居中，得自己算位置。核心逻辑是：拿到目标元素的offsetLeft和宽度，再结合容器可视宽度，算出需要滚动的scrollLeft值。
关键不是“滚动到”，而是“滚动到居中位置”。别信网上一堆直接scrollIntoView的代码，那只是对齐左边缘。
- 用
uni.createSelectorQuery()获取目标元素boundingClientRect，比ref更可靠（尤其列表动态渲染时） - 滚动公式：
scrollLeft = target.left - (containerWidth - target.width) / 2 - 务必加
scroll-with-animation属性，否则iOS无动画；H5端需用scrollTo配合behavior: 'smooth' - 防连续点击：加
isScrolling锁，300ms内重复点击直接return
分类菜单数据异步加载时，scroll-into-view为啥总失效
因为scroll-into-view是声明式属性，只在初始渲染或data变化时触发一次。如果分类列表是uni.request回来再setData，此时DOM还没更新，scroll-into-view已提前“尝试”过并放弃。
这不是bug，是设计使然——它不监听DOM插入，只响应Vue/uni的数据响应式更新时机。
- 绝对不要在
then里直接赋值scroll-into-view，要等$nextTick后再设 - 更稳的做法：不用
scroll-into-view，改用this.$refs.scrollView.scrollIntoView（需给scroll-view加ref） - App端若仍失效，检查是否启用了
renderjs或weex模式，这两者会干扰节点查询
横向导航居中联动内容区，为什么scroll-view嵌套scroll-view会失灵
两个scroll-view嵌套时，内层滚动会吞掉外层的touch事件，导致手指一碰就触发内层滚动，外层导航根本点不中。这是WebView底层事件冒泡限制，uni-app无法绕过。
真实项目里，90%的“联动失败”其实是因为这个结构问题，而不是逻辑写错了。
- 导航区和内容区必须分开，用
view做导航容器，scroll-view只负责内容区滚动 - 联动靠
scroll事件监听+节流，而非嵌套滚动 - 监听内容区
scroll事件时，用scrollTop推算当前可视区域对应哪个分类，再调用导航滚动逻辑 - 注意
scroll-top在H5和小程序单位不同（px vs rpx），统一用uni.upx2px换算
最麻烦的其实是滚动临界点判断——比如内容区刚好卡在两个分类交界处，该高亮谁。这时候不能只看scrollTop，得结合每个分类内容块的实际offsetTop和高度做区间匹配。这点很容易被忽略，但直接影响体验是否“跟手”。
