javascript事件循环中，宏任务与微任务严格按“同步→微任务队列清空→下一个宏任务”顺序执行；示例输出为1→6→3→4→2→5，queuemicrotask和promise.then同属微任务队列，async/await的await也产生微任务。
在 JavaScript 中，宏任务（macrotask）和微任务（microtask）的执行顺序是事件循环的核心机制。要精准测试它们的先后顺序，关键不是“猜”或“看控制台输出”，而是用可复现、无干扰、能明确标记任务类型的代码结构，结合 console.log 的时序 + 任务插入位置的严格控制来验证。
用 setTimeout 和 Promise 配合标记验证执行顺序
这是最直接、最可靠的基础测试方式。注意：必须确保所有任务都在同一个事件循环周期内被调度（即同步代码中一次性注册），才能观察到微任务清空再执行下一个宏任务的规律。
- 错误写法：在 setTimeout 回调里再 new Promise —— 这会把微任务推到下一个循环，破坏对比性
-
正确写法：所有
setTimeout和Promise.resolve().then()都在同步脚本中立即调用
示例代码：
console.log('1'); // 同步
setTimeout(() => console.log('2'), 0); // 宏任务A（下一轮循环的宏任务队列头）
Promise.resolve().then(() => console.log('3')); // 微任务A（本轮循环微任务队列）
Promise.resolve().then(() => console.log('4')); // 微任务B（同队列，紧随A后）
setTimeout(() => console.log('5'), 0); // 宏任务B（排在宏任务A之后）
console.log('6'); // 同步
输出一定是：1 → 6 → 3 → 4 → 2 → 5。
说明：同步执行完后，先清空全部微任务（3、4），再取一个宏任务执行（2），之后才轮到下一个宏任务（5）。
用 queueMicrotask 显式插入微任务，避免 Promise 开销干扰
queueMicrotask 是 ES2020 引入的原生微任务调度 API，比 Promise.then 更轻量、语义更清晰，且不涉及 Promise 状态管理，适合做纯净测试。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 它和
Promise.then属于同一微任务队列，执行时机完全一致 - 可用于对比不同微任务来源是否真的“同级”
示例：
console.log('start');
queueMicrotask(() => console.log('micro1'));
Promise.resolve().then(() => console.log('micro2'));
setTimeout(() => {
console.log('macro1');
queueMicrotask(() => console.log('micro3'));
}, 0);
console.log('end');
输出：start → end → micro1 → micro2 → macro1 → micro3
验证了：宏任务内部产生的微任务，仍会在该宏任务结束后立即执行（而不是等到下一轮宏任务）。
用 async/await 拆解隐式微任务链，观察嵌套行为
async 函数返回 Promise，await 后的表达式结果会被包装进微任务。这有助于测试“微任务中再产生微任务”的层级关系。
-
await Promise.resolve()等价于Promise.resolve().then(...) - 多个
await不会跨宏任务，只要它们在同一个 async 函数内
示例：
console.log('a');
setTimeout(() => console.log('b'), 0);
async function foo() {
console.log('c');
await Promise.resolve();
console.log('d');
await Promise.resolve();
console.log('e');
}
foo();
console.log('f');
输出：a → c → f → d → e → b
说明：foo() 同步部分执行 c 和 f；两个 await 分别将 d 和 e 推入微任务队列，连续执行；最后才执行宏任务 b。
避免常见干扰因素，保证测试精准
真实测试中，以下因素容易导致结果“看似不符”，实则机制未变：
-
浏览器 DevTools 的 console.log 延迟渲染：建议搭配
performance.now()打时间戳，或用数组 push + 最后统一打印 - Node.js 版本差异：v11+ 已对齐浏览器行为（每个宏任务后清空微任务），旧版 Node 可能有偏差，务必确认版本
-
其他异步源混入：如
fetch、IntersectionObserver、requestIdleCallback等，它们不属于标准宏/微任务分类，需排除 - 定时器最小延迟限制：即使设为 0，实际可能 > 0ms，但不影响相对顺序，只影响绝对时间
