微任务需通过封装调度逻辑、闭包固化参数、双队列私有化及promise链控制顺序来保障逻辑原子性：所有判断、取任务、执行须在单个微任务内完成，避免状态错乱。
微任务本身不天然具备“执行不被干扰”的原子性，但通过合理设计调度边界和操作封装，可以让关键流程在逻辑上不可分割——即从外部观察，整个决策与执行过程像一个整体，不会因事件循环切换而状态错乱。
把整套调度逻辑塞进单个微任务
所有判断、选择、入队、触发动作，必须在同一个 queueMicrotask 或 Promise.resolve().then() 回调里完成：
- 读取当前队列状态（比如检查 immediateQueue 是否为空）
- 决定执行哪个任务（按优先级选、按 key 去重判断）
- 从队列中取出任务并调用执行函数
- 若需延迟或插队，也在此回调内安排下一个微任务
这样避免了“读完队列 → 被其他宏任务抢占 → 再回来取任务”导致的状态不一致。
闭包固化上下文，防止执行时参数漂移
任务不是直接传函数，而是由闭包工厂生成：
- 立即捕获 userId、timestamp、timeout 等关键参数，后续变量变化不影响该任务
- 任务对象自带唯一 key（如
load-user-123），用于去重或合并判断 - 执行函数体内不查外部变量，只依赖闭包封存的快照
双队列私有持有，杜绝并发误操作
调度器用 IIFE 封装，两个队列数组（immediateQueue 和 backgroundQueue）完全不暴露给外部：
- 所有
push、shift、length操作都在同一作用域内进行 - 没有全局引用，也就无法被其他代码意外修改或清空
- 配合 WeakMap 实现 key 级去重，判断和入队在同步阶段一气呵成
高优任务插队要控制微任务顺序
普通任务走 queueMicrotask(fn)，紧急响应类任务可利用 Promise 链控制执行次序：
- 用
Promise.resolve().then(() => highPriorityTask)插入当前微任务队列头部 - 避免使用
setTimeout(..., 0)，它属于宏任务，必然被延后到下一轮事件循环 - 注意不要无节制插队，否则会饿死低优任务
