微任务执行顺序在单个事件循环内是确定的，即当前宏任务结束后立即清空本轮微任务队列，新微任务追加至队列末尾并持续执行直至为空；但跨宏任务的微任务因触发时机受网络、系统负载等影响而不具备可预测性，且无法消除并发写入共享状态的竞态问题。
微任务本身执行顺序是确定的——它严格遵循“当前宏任务结束后立即清空整个微任务队列”的规则，且新产生的微任务会追加到本轮队列末尾并继续执行，直到为空。所谓“不可预测性”并非来自微任务机制本身，而是出现在并发场景下多个独立微任务队列之间的调度竞争，或与外部异步源（如网络响应、定时器、用户输入）交织时引发的时序不确定性。
微任务队列内部是确定的，但跨队列不保证先后
每个事件循环轮次只处理一个宏任务，其结束后清空的是“当前轮次积累的微任务队列”。问题在于：不同宏任务触发的微任务，彼此不在同一个队列中。例如：
- 一个 Promise 在 fetch 回调中 resolve → 产生微任务 A
- 另一个 Promise 在 setTimeout 回调中 resolve → 产生微任务 B
- A 和 B 分属两个不同宏任务（fetch 回调 vs setTimeout 回调）触发的微任务队列
- 谁先触发宏任务，谁的微任务就先执行；而宏任务触发时间受网络延迟、系统负载、浏览器节流等影响，无法精确控制
并发写入共享状态时，微任务无法消除竞态
微任务执行快、优先级高，但不等于线程安全。当多个微任务修改同一变量或 DOM 节点，仍会发生竞争：
- 两个独立的 Promise.then 都执行 document.body.innerHTML += 'x'，结果可能丢失或错乱
- React 中多个 useState 更新若在不同微任务中触发，可能因批量更新机制未生效而出现中间状态泄露
- 解决方式不是避免微任务，而是引入协调机制：使用 ref + 标识符判断最新请求、用 queueMicrotask + 单一处理函数串行化写入、或改用消息队列模型解耦读写
嵌套与递归微任务易掩盖真实依赖关系
开发者有时用 Promise 链或 queueMicrotask 模拟“顺序执行”，但若逻辑本应并行却强行串行，反而放大时序敏感性：
- 比如将三个独立 API 请求用 then 链式调用，第二个必须等第一个返回才发，实际可并发，却人为制造了顺序依赖
- 又如在每个 then 中再创建新的 Promise.resolve().then(...)，形成深层嵌套，使错误定位和取消变得困难
- 正确做法是明确区分“数据依赖”和“执行顺序”：有依赖用链，无依赖用 Promise.all，需控制节奏则用分片 + queueMicrotask
浏览器渲染时机进一步模糊感知顺序
微任务全部执行完后才进入渲染阶段，但渲染本身不保证原子性，且受 requestAnimationFrame、CSS 动画、布局抖动等干扰：
- 两个微任务分别修改同一元素的 class 和 style，最终样式取决于最后执行的那个
- 但用户看到的视觉变化，还受渲染帧率、GPU 合成、图层提升等因素影响，未必与微任务执行顺序完全对应
- 因此，依赖“微任务先于渲染”做 UI 反馈时，应配合 nextTick 或 requestAnimationFrame 做最终对齐，而非仅靠微任务排队
