优先用 scroll-into-view（ID 驱动），但异步/动态内容必须用 scroll-top（数值驱动）；左侧禁用滚动、右侧单向驱动可避免抖动；高亮判定需按视口重叠面积而非简单位置比较。
scroll-view 的 scroll-top 和 scroll-into-view 到底该用哪个？
点击左侧分类跳转右侧内容，本质是「控制滚动位置」。uni-app 提供两个主流方式：scroll-top（数值驱动）和 scroll-into-view（ID 驱动），但它们适用场景完全不同。
用 scroll-into-view 最省事：只要右侧每个分类区块有唯一 id（比如 id="cat-2"），点击时直接赋值即可。但它有个硬伤——只在 DOM 渲染完成、节点真实存在后才生效；如果右侧内容是异步加载或 v-for 未完全渲染，scroll-into-view 会静默失败，不报错也不滚动。
scroll-top 更可控：你算出目标区块顶部距离容器顶部的像素值，直接赋给 scroll-top。它不依赖节点 ID，也不怕异步延迟，但必须提前知道每个区块的高度并累加计算。
- 静态结构、数据一次性加载 → 优先用
scroll-into-view，代码少、易维护 - 含图片/懒加载/动态增删项 → 必须用
scroll-top+boundingClientRect动态测算 - 小程序真机上
scroll-into-view在某些安卓机型有偏移 bug，scroll-top更稳
为什么右侧一滚动，左侧高亮就错位？
核心原因：没等 DOM 完全就绪就去查高度，或者滚动监听里没做防抖/节流，导致 scrollTop 值频繁抖动、判断逻辑被干扰。
典型错误是 onLoad 里直接调 uni.createSelectorQuery()，但此时 v-for 还没生成真实节点。正确做法是等 $nextTick 或使用 query.exec() 的回调确保节点已挂载。
- 高度计算必须放在
onReady或$nextTick后执行，不能只靠onLoad - 每个分类区块要用
class="menuDetailBox"统一标识，别用嵌套过深的选择器，否则boundingClientRect取不到准确 height -
@scroll回调里不要直接写复杂逻辑，先用throttle包一层，避免每帧都触发判断 - 判断当前高亮项时，别用
===比较scrollTop和累计高度，要允许小范围误差（比如 ±10px），否则滑到边界时反复切换
左右同步滚动怎么避免“来回抖”？
监听左边 scroll 事件去改右边 scroll-top，同时又监听右边 scroll 去改左边 —— 看似对称，实则形成循环触发，尤其在快速拖拽时，两边 scrollTop 互相覆盖，视觉上就是“抽搐式滚动”。
根本解法是「单向驱动」：只让右边 scroll-view 成为唯一滚动源，左边 scroll-view 改为只读（禁用 scroll-y），通过 scroll-top 被动跟随。这样既满足联动效果，又彻底规避冲突。
- 左侧
scroll-view去掉scroll-y，只保留点击功能，它本身不滚动 - 右侧
scroll-view开启scroll-y，负责所有滚动行为 - 左侧点击时，只更新右侧的
scroll-top，不碰左侧自己的滚动状态 - 右侧滚动时，只更新左侧的
currentIndex，不反向设置左侧scroll-top
如何让左侧高亮条紧贴当前分类不漂移？
单纯靠 :class="{ currentMenu: currentIndex === index }" 是不够的。当右侧内容高度不均（比如某分类只有 1 行文字，另一分类有 20 张图），滚动过程中，当前区块可能只露出顶部 5px，但左侧仍高亮——用户会觉得“还没到那儿就亮了”。
真正靠谱的做法是：把“当前分类”的判定逻辑从「谁在视口内」升级为「谁占据视口最多面积」。这需要在 @scroll 回调里，遍历所有分类区块，计算每个区块在可视区域内的重叠高度，取最大值者为当前项。
- 别只比
scrollTop ，要算Math.max(0, Math.min(blockBottom, viewBottom) - Math.max(blockTop, viewTop)) - 区块 top/bottom 值必须每次滚动都重新 query，不能只初始化一次（因为页面缩放、字体加载都可能改变布局）
- 首次进入页面时，手动触发一次
scrollRight，保证初始高亮正确
这事听着细，但用户一眼就能感知——高亮不准，整个联动就显得廉价。宁可多算几次，也不能靠猜。
