用事件委托+element.matches()实现滚动高亮联动，本质是避开高频scroll事件直接操作dom的性能陷阱，转而用一次监听+精准匹配替代遍历判断。
在电商分类侧边栏中，用事件委托 + Element.matches() 实现滚动高亮联动，本质是**避开高频 scroll 事件直接操作 DOM 的性能陷阱，转而用一次监听 + 精准匹配替代遍历判断**。它不依赖反复计算每个区块的 offsetTop，也不靠 IntersectionObserver（兼容性或小程序支持有限），特别适合 uni-app 或 H5 中对响应速度和内存占用敏感的场景。
为什么传统 scroll 监听容易卡顿
直接在 @scroll 里循环比对每个分类区块位置，会导致：
- 每帧触发多次，iOS 下尤其明显（scroll 事件频率远高于 requestAnimationFrame）
- 每次都要调用
uni.createSelectorQuery()或getBoundingClientRect()，触发重排重绘 - 区块高度不一时，手动算可视区域边界逻辑易出错、难维护
事件委托 + matches 的核心思路
不监听滚动本身，而是监听右侧 scroll-view 的 滚动结束瞬间（利用 @scrollend，或退化为节流后的 @scroll），再通过委托到容器，用 matches() 快速定位当前“最靠近顶部”的分类区块。
关键前提是：右侧每个分类区块有唯一合法 id，且结构清晰，例如：
<view id="category-food">饮品</view><br><view id="category-snack">零食</view><br><view id="category-dairy">乳品</view>
左侧菜单项也按约定命名，如 data-id="category-food"。
具体实现三步走
1. 给右侧 scroll-view 绑定节流滚动监听
- 不用
onPageScroll（仅页面级有效） - 用
@scroll+setTimeout或requestIdleCallback做轻量节流（300ms 内只处理最后一次） - 滚动停止后，获取当前
scrollTop值
2. 用事件委托捕获“可视区首个区块”
- 不遍历所有分类节点，而是从
scrollTop附近开始向上/向下找最近的区块 - 借助
document.elementFromPoint(x, y)或更稳妥的：用querySelectorAll('[id^="category-"]')获取全部区块，再用Array.prototype.find()配合matches()判断是否满足“顶部已过半进入视口” - 例如：
el.matches(':is([id^="category-"])') && el.offsetTop
3. 高亮同步只需一次 DOM 更新
- 拿到匹配到的区块 id（如
"category-snack"）后，直接更新左侧data-id匹配项的 class - 避免
v-for全量重渲染，用:class="{ active: currentId === item.id }"即可 - 高亮状态变更后，
this.currentId = id触发响应式更新，不手动操作 DOM
注意事项与避坑点
这个组合不是万能银弹，需注意：
-
matches()在低版本 Android WebView 中需 polyfill（Element.prototype.matches || Element.prototype.msMatchesSelector） - 务必确保右侧每个区块
id合法（纯字母数字下划线），否则querySelector找不到，matches也无效 - 不要在
@scroll里直接调this.$nextTick——节流后再 nextTick 更稳 - 若分类区块含动态内容（图片懒加载），需等其渲染完成再做匹配，可用
offsetHeight > 0简单校验
