Vue的微任务更新机制并非并发而是批量同步执行，所有effect在下一个微任务中不可中断地依次执行，导致高密度更新时主线程阻塞；应通过虚拟滚动、v-memo、批量赋值或markRaw等方式减少更新量。
“微任务并发”这个说法本身不准确——Vue 的更新机制里没有真正的并发，只有微任务批量调度。它不是把多个更新拆开、交替执行，而是把所有待更新的 effect 收集起来，在下一个微任务中一次性、同步、不可中断地执行完。所以当多组件同时响应数据变化（比如 500 个 slider 同时 reactivity 触发），哪怕每个更新都很轻，合起来仍会阻塞主线程，造成卡顿。
为什么微任务调度会卡？
关键在于“不可中断”和“全量 flush”：
- 所有响应式依赖触发后，effect 被推入一个队列，去重后统一在
Promise.then中调用flushJobs -
flushJobs是纯同步循环：逐个执行每个组件的更新函数（componentUpdateFn），期间无法让出控制权给用户交互或渲染 - 哪怕单个组件更新只需 0.1ms，500 个就是 50ms —— 超过一帧（16.7ms），必然掉帧、滚动卡顿
绕过批量更新瓶颈的实用方法
不改 Vue 内核，就只能从使用方式上规避高密度更新：
-
用
v-memo或shouldUpdate按需跳过：对列表中大量静态/半静态组件（如只读 slider），显式声明哪些 props 变了才更新，避免无意义触发 - 手动节流响应式源头：不要让 500 个响应式值同时变化。改用单个数组 ref + 批量赋值，或加防抖（如 slider 拖动中暂存 value，松手再统一提交）
-
降级为非响应式渲染：对纯展示型组件（如只读 slider），用
markRaw包裹数据，配合render函数或v-html渲染，彻底脱离响应式系统 -
强制分片：用
setTimeout切成多轮微任务（慎用）：
例如将 500 项拆成每批 50 项，用setTimeout(() => { /* 更新一批 */ }, 0)分 10 轮触发，让浏览器有机会重绘
比“调度优化”更有效的根本解法
与其在更新阶段挣扎，不如减少需要更新的量和频次：
-
虚拟滚动（Virtual Scrolling）：只渲染可视区域内的组件（如
vue-virtual-scroller）。500 个 slider → 实际 DOM 节点可能只剩 10 个 -
样式层优化：给滚动容器加
-webkit-overflow-scrolling: touch（尤其 iOS），启用原生滚动加速；避免在滚动中触发动态计算 -
结构精简：确认每个 slider 组件内部是否嵌套过深、是否绑定了多余 watch / computed；用
defineComponent({ setup() { return () => [...] } })避免 setup 函数重复执行
