scroll-view嵌套+scroll-into-view是uni-app纵向选项卡联动唯一可行方案，需严格对齐左右高度、滚动行为与ID标识，并通过offsetTop比对+节流+ref缓存实现精准高亮与滚动。
scroll-view 嵌套 + scroll-into-view 是唯一可行路径
uni-app 没有原生 sticky 或 sync-scroll，纵向选项卡联动必须靠两个 scroll-view 手动协同。左侧是菜单列表，右侧是内容区块，二者高度、滚动行为、id 标识必须严格对齐，否则联动会错位或失效。
常见错误现象：scroll-into-view 不生效、右侧滚动时左侧不更新、点击左侧后右侧跳到错误位置、真机白屏或卡顿。
- 左侧
scroll-view必须设scroll-y="true"且带固定高度（不能用height: auto） - 右侧
scroll-view同样要设scroll-y="true"，并加show-scrollbar="false"避免干扰视觉 - 每个右侧内容区块必须有唯一
id（如category-0），且不能以数字开头 - 不要在
onPageScroll里查 DOM —— 它只监听页面级滚动，而联动必须基于scroll-view的bindscroll
右侧滚动时如何精准匹配左侧高亮项
核心不是监听「滚动了多少」，而是判断「当前可视区域顶部对齐的是哪个区块」。直接用 scrollTop 和各区块 offsetTop 做差值比对最稳定，比 boundingClientRect().top 更少受容器偏移影响。
性能关键点：bindscroll 每帧都触发，但 DOM 查询昂贵，必须节流（例如 50ms）；且每次只查一次所有区块的 offsetTop，缓存进数组复用。
- 给每个右侧区块加
ref（如:ref="'category' + index"），比用querySelector更快更可靠 - 高亮逻辑：遍历
refs数组，找第一个满足item.offsetTop 的索引（+100 是容错偏移，防临界抖动） - 找到后用
this.$nextTick(() => { this.leftActiveIndex = index })更新左侧状态，再触发左侧scroll-into-view - 别忘了在
data中定义leftActiveIndex并绑定到左侧菜单的 class 切换逻辑上
左侧点击如何让右侧滚动到准确位置
不能只靠 scroll-into-view，因为右侧内容可能还没渲染完（尤其用 v-for 动态生成时）。必须等 DOM 就绪后再滚动，否则会滚到 0 位置或失败。
典型错误：直接在点击事件里赋值 scroll-into-view="category-2"，但此时 category-2 节点还不存在。
- 点击左侧后，先设
this.rightScrollInto = 'category-' + index - 紧接着用
uni.createSelectorQuery()查该节点的offsetTop，确认存在后再调用scroll-view的scrollTo方法（需 ref 获取实例） - 或者更稳妥：在
$nextTick后延时 30ms 再执行滚动，确保 v-for 渲染完成 - 如果右侧用了
swiper替代scroll-view，则必须用current控制，而非scroll-into-view
uv-vtabs 的 chain=true 联动模式要注意什么
uv-vtabs 是 uv-ui 提供的封装组件，开启 chain=true 后自动处理左右联动，但它的前提非常具体：右侧内容必须用 uv-vtabs-item 循环渲染，且每个 item 内部结构要符合约定（含 childrens 数组）。
容易被忽略的坑：hdHeight 参数。只要右侧顶部有固定 header（比如欢迎语、搜索栏），就必须传这个值，否则联动计算会整体下移，导致高亮错位。
- header 高度单位必须和
hdHeight一致（如100rpx就传hdHeight="100rpx"） - 若右侧没 header，不传
hdHeight（默认为 0），传了反而出错 -
uv-vtabs-item内部不能嵌套其他scroll-view，否则会干扰内部滚动监听 - 不建议在
uv-vtabs外层再套一层scroll-view，会导致事件冒泡异常或滚动冲突
联动真正难的不是写代码，是让左右两侧的 DOM 位置、滚动时机、数据索引三者在任意设备、任意缩放、任意网络延迟下都对得上。尤其是真机调试时，iOS 和安卓的 scroll 事件节奏差异、小程序基础库版本对 scroll-into-view 的支持程度，都可能让看似正确的逻辑突然失效。
