promise 的 .then()、.catch() 和 .finally() 回调属于微任务，因 ecmascript 规范要求状态变更后必须将其加入微任务队列，在当前宏任务结束后立即一次性清空执行，兼顾响应性与非阻塞性。
promise 的 .then()、.catch() 和 .finally() 回调属于微任务，不是因为 promise 本身“天生特殊”，而是 javascript 规范（ecmascript）明确要求：当 promise 状态变为 fulfilled 或 rejected 时，其关联的处理函数必须被加入微任务队列，并在当前宏任务结束后立即、一次性清空执行。
微任务的设计目标是“紧接同步逻辑之后执行”
它解决的是异步回调的实时性与非阻塞性之间的平衡：
- 同步回调会阻塞主线程，导致后续代码无法运行，CPU 利用率低，且无法支持延迟绑定
- 宏任务（如 setTimeout）要排队等完整轮次，可能被大量任务延迟，响应不及时
- 微任务插在当前宏任务末尾、渲染之前，既不阻塞同步流程，又比宏任务更早执行，兼顾效率与响应性
事件循环中微任务有强制清空机制
每次宏任务执行完毕后，JavaScript 引擎不会直接取下一个宏任务，而是暂停宏任务调度，转而逐个执行所有已入队的微任务，直到队列为空：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 哪怕 Promise 立即 resolve，.then() 回调也不会在同步代码中运行，而是排队等本轮结束
- 链式调用如
Promise.resolve().then(a).then(b).then(c)，a、b、c 会依次进入微任务队列，并在同一次清空过程中连续执行 - 中间插入的 setTimeout 回调一定排在这一轮微任务全部执行完之后
Promise.resolve() 本身是同步的，真正产生微任务的是它的回调
调用 Promise.resolve(42) 立刻返回一个已 fulfilled 的 Promise 对象，这一步完全同步；真正触发微任务的是后续注册的 .then()：
- 状态变更（fulfilled/rejected）不直接执行回调，而是将其调度进微任务队列
- 这是 Promise/A+ 规范的核心约定，保障了时序确定性——无论 Promise 如何创建，只要用了 .then，回调就一定是微任务
- 其他微任务来源（如 MutationObserver、queueMicrotask）共享同一队列和执行时机，但 Promise 是最常用、最标准化的入口
这种设计支撑了现代前端的关键行为
微任务的高优先级和紧邻执行特性，被框架和浏览器深度依赖：
- React 的 setState 在早期版本中利用 Promise 微任务实现批量更新和状态合并
- Vue 的 nextTick 基于微任务（优先用 Promise.finally，降级到 MutationObserver）确保 DOM 更新后立刻响应
- async/await 本质是 Promise 语法糖，await 后的代码会被包装成 .then 回调，同样走微任务路径
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
