宏任务队列严格遵循fifo原则，事件回调由宿主环境动态触发后追加到队列尾部，确保因果顺序和单线程一致性；微任务则由js引擎调度，在每个宏任务结束后立即清空整个微任务队列。
因为宏任务队列遵循“先进先出”（FIFO）原则，而事件回调（如点击、键盘、定时器到期等）是由宿主环境（浏览器或 Node.js）在事件发生时才生成并入队的——它不是提前安排好的，而是动态触发后追加到队列尾部。
事件回调不是预先排好的“计划”，而是实时产生的“通知”
比如用户点击按钮、setTimeout计时结束、fetch响应到达，这些都不是 JS 引擎主动发起的，而是外部环境检测到条件满足后，才把对应的回调函数作为一个新宏任务推入队列末尾。这保证了事件的因果顺序：谁先发生，谁的回调就先排队。
避免抢占正在执行的任务，保障单线程一致性
JS 主线程任何时候只能干一件事。如果某个事件回调被插到队列头部，就等于强行中断当前运行的代码，破坏了同步逻辑的可预测性。所以所有宏任务都必须老老实实排队，等当前宏任务（包括其内部所有同步代码和微任务）彻底执行完，事件循环才会从队列头取下一个宏任务。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
与微任务的关键区别就在这里
微任务（如 Promise.then）由 JS 引擎自身调度，它们不进宏任务队列，而是进独立的微任务队列，并且规则是：
- 每个宏任务结束后，必须清空整个微任务队列；
- 新加入的微任务也会被立即纳入本轮清空范围。
而宏任务没有这种“插队权”，它们只接受 FIFO 管理，确保调度公平、可追溯。
实际表现举例
假设你同时触发：
- 一个 setTimeout(fn, 0)（宏任务）
- 一个 click 事件（宏任务）
- 一个 Promise.resolve().then(cb)（微任务）
即使 click 在 setTimeout 之后几毫秒才发生，它的回调仍会排在 setTimeout 回调后面；但 Promise 的 cb 会紧接在当前脚本结束之后立即执行，无需等其他宏任务。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
