Vue响应式更新优先级由任务排序与执行阶段控制：父组件effect ID更小故先于子组件执行，用户副作用ID最小优先于渲染，微任务内自动去重，scheduler可自定义调度逻辑。
Vue.js 响应式系统触发更新的优先级调度机制，核心在于任务排序 + 执行时机控制，不是靠“高/低优先级”标签，而是通过 job 的自然顺序与执行阶段划分实现逻辑上的优先保障。
组件更新按依赖链路排序：父先于子
当多个组件的渲染 effect 被同时触发（比如修改一个共享状态），Vue 会对 job 队列按 effect id 升序排列。这个 id 在创建时就已分配，且父组件的 effect 总是比其子组件更早创建、id 更小。因此刷新时父组件 render 先执行，子组件后执行——避免子组件读取到父组件尚未更新的旧 props 或 context，防止状态撕裂和警告。
- 例如：修改
user.profile.name，触发 Profile 组件（父）和 Avatar 组件（子）更新，Profile 的 job 一定排在 Avatar 前面 - 这种排序发生在
flushJobs开始前，是队列层面的确定性行为，不依赖手动标记
用户副作用与渲染副作用分层执行
Vue 内部将不同类型的 effect 分配了不同范围的 id 区间：
- 用户 watchEffect / computed：id 较小，优先执行（通常在渲染前）
- 组件 render effect：id 居中，紧随其后
- 过渡、指令等内部副作用：id 更大，最后执行
这样设计确保 computed 值在 render 前已更新，watch 监听能拿到最新状态，而 DOM 操作类逻辑（如 v-model、v-show）总是在视图生成之后才介入，符合数据流预期。
立即学习“前端免费学习笔记（深入）”；
微任务内批量合并，天然屏蔽重复
同一轮事件循环中，对同一个响应式属性的多次 set，只会触发一次对应的 effect 入队；即使多个 ref 同时变化，只要它们最终触发的是同一个组件的 render，该组件也只进队一次。
- 底层靠
jobQueue是 Set 结构去重，key 是 effect 实例本身 - 哪怕你在 for 循环里连续赋值
count++10 次，最终也只触发一次组件重新渲染 - 这并非“降低优先级”，而是通过去重让真正需要的更新更干净、更及时
可干预的调度入口：自定义 scheduler
开发者可通过 effect 或 watchEffect 的 scheduler 选项接管执行节奏，实现逻辑级优先控制：
- 用
queueMicrotask(job)替代默认调度，保持微任务语义但绕过 Vue 内部队列管理 - 写
scheduler: (job) => job()强制同步执行（慎用，可能破坏父子顺序） - 结合
flushSync包裹关键更新，让某次修改立即 flush，跳过排队——适合表单校验反馈、焦点管理等强同步场景
