setTimeout(fn, 0) 并非马上执行，而是将fn推入宏任务队列，需等待同步代码和所有微任务执行完毕后，在下一轮事件循环中执行，且受浏览器最小延迟限制（通常≥4ms）。
setTimeout(fn, 0) 真的“马上执行”吗？
不，它根本不会马上执行。setTimeout(fn, 0) 只是把 fn 推进宏任务队列，等当前同步代码跑完、所有微任务清空、下一轮事件循环开始时才轮到它。
- 浏览器会对
0做最小延迟限制（通常 ≥ 4ms），非活跃标签页甚至可能节流到 1000ms - 它和
Promise.resolve().then(...)不在同一个优先级：微任务总比宏任务先执行 - 常见错误现象：
setTimeout(() => console.log(2), 0)总是晚于Promise.resolve().then(() => console.log(1))，输出一定是1→2
Promise 构造函数里的代码为什么是同步执行的？
因为 new Promise(executor) 中传入的 executor 函数会立即被调用——这是规范强制要求的同步行为。真正异步的是 resolve() 或 reject() 调用后触发的 .then() 回调，它们被推入微任务队列。
-
executor里写的所有同步逻辑（比如console.log('in promise')）会在new Promise这一行立刻执行 -
resolve()本身不执行回调，只把回调标记为“就绪”，等当前宏任务结束、微任务队列清空时才批量执行 - 滥用
Promise包裹同步代码（如Promise.resolve().then(() => doSync())）会引入不必要的微任务调度开销
async/await 的 await 后面代码到底算什么任务？
await 后面的代码会被编译成 Promise.then() 形式，所以属于微任务，不是宏任务。
-
await Promise.resolve()之后的语句，等价于写在.then()里，会排队进微任务队列 - 这意味着它一定在当前宏任务结束后、下一个宏任务开始前执行，绝不会被
setTimeout插队 - 注意：如果
await的是普通值（如await 42），V8 会直接把它包装成已 resolve 的 Promise，仍走微任务流程
什么时候该用 queueMicrotask 而不是 setTimeout？
当你需要“紧接当前操作之后、但在下一个宏任务之前”执行一段逻辑时，queueMicrotask 是更轻量、更精确的选择。
立即学习“Java免费学习笔记（深入）”；
-
queueMicrotask不经过定时器线程，无最小延迟限制，也不产生宏任务调度开销 - 适合场景：DOM 更新后立即读取布局（避免强制同步重排）、批量收集变更后统一响应、实现细粒度的控制流让步
- 兼容性注意：IE 不支持，Node.js ≥ 12.0 和现代浏览器都可用；若需兼容旧环境，可用
Promise.resolve().then()替代
setTimeout，就可能让原本能“连贯执行”的逻辑被渲染或用户输入打断——这点在做动画、表单校验或状态同步时特别容易翻车。 
