你是否曾经疑惑过：为什么 setTimeout 后面的代码会先执行？为什么 Promise 能解决回调地狱？JS 明明是单线程，却能处理网络请求、定时任务？

一、进程与线程：先搞懂“董事长”和“经理”

在了解 JS 之前，需要先认识两个操作程序层面的概念：进程和线程。

• 进程 ：可以理解为一个正在运行的程序实例。操作程序会为它分配独立的内存空间、文件句柄等资源。每个进程都有一个唯一的 PID。就像一个董事长负责统筹全局、分配资源。
• 线程 ：是进程内的执行单元，一个进程至少有一个线程。线程共享进程的资源，负责具体的代码执行。其实，就像经理在董事长的资源支持下真正去干活。怎么说呢，

C++、Java 这类程序级语言。支持多进程多线程架构。它们可以同时开启多个线程并行执行任务，效率极高，但复杂度也高。

而 JavaScript 的设计理念恰恰相反：简单、易用、避免复杂性。

二、JS 为什么是单线程？

浏览器中的 JavaScript 最初设计用于操作 DOM、响应使用者交互。如果支持多线程同时修改同一个 DOM 节点，就会出现冲突。为了避免这种复杂性，JS 选择了一条最简单的路——单线程。

单线程带来了一个严重问题：如果某段代码执行时间很长。后续代码就会被阻塞，页面会“卡死”。这显然无法接受，

于是JS 的设计者引入了异步机制**：

三、JS 执行机制：同步优先·异步靠“事件循环”

// 同步代码
console.log;// 异步代码
setTimeout => {
console.log;},0)，console.log;其实，

再看答案是。start → end → timeout

背后的执行机制如下：

1. 启动进程：JS 引擎创建进程并分配资源。
2. 开启主线程：主线程开始逐行执行代码。
3. 同步任务优先：alert遇到同步语句立即执行；遇到 setTimeout 时将计时器交给浏览器的 Web API 处理，并把回调放入任务队列
4. 继续执行同步任务：`console.log` 被立即打印。话说回来，
5. 事件循环登场：
6. 执行异步回调：

说到更深入。宏任务与微任务

当你在实际项目里混用 alert/setTimeout 和 ,常常不知道到底哪个先跑。下面来拆解两类任务：

• 宏任务：`setTimeout`、`setInterval`、I/O 操作、UI 渲染等。说起来，
• 微任务：`Promise.n/catch/finally`、`MutationObserver` 等。

执行顺序规则：每完成一个宏任务后会立即清空当前微任务队列，接下来才取下一个宏任务。

setTimeout => console.log,0);Promise.resolve.n => console.log);console.log，// 输出顺序：同步代码 → 微任务1 → 宏任务1

This ordering is key to mastering Promise behavior.

四、异步流程控制：为什么需要 Promise？

传统回调写法容易陷入“回调地狱”，导致代码难以阅读和维护。说到举个例子，

getUsers => {
users.forEach(user => {
getUserDetail => {
console.log;})，});
})，

The nested structure quickly becomes unreadable as more steps are added. ES6 引入的 **Promise** 给了我们统一且可链式调用的方式，解决主要问题了这个痛点。

五、Promise 完全教程

什么是 Promise？

`Promise` 是一个容器 内部保存着某个未来才会结束的异步操作结果。它通过三种状态来描述生命周期：

• `pending` – 初始状态，还未决定成功还是失败；
• `fulfilled` – 成功完成；
• `rejected` – 失败结束；

基本用法

 const p = new Promise => {
console.log;// 同步立即打印
// 模拟耗时操作
setTimeout => {
// 成功调用 resolve
// resolve;// 失败调用 reject
reject;},1000)，});console.log，// 打印 pending 状态
p.n(data => {
console.log;})
.catch(err => {
console.error;})
.finally => {
console.log;})，

• executor 函数：在 `new Promise` 时**立即同步** 执行，所以 `Executor 开始运行` 会第一时间出现。
• resolve / reject：由开发者自行调用，以改变 Promise 状态并触发对应回调。
• n / catch / finally：返回新的 Promise，实现链式调用。
• 状态不可逆转：一旦从 `pending` 转为 `fulfilled` 或 `rejected` 就不可再变。

说到实际场景，使用 fetch

 console.log;fetch
.n) // 返回另一个 Promise
.n)
.catch);怎么说呢，console.log;// 输出顺序： start → end →

`fetch` 本身返回的是 Promise。所以即使网络请求耗时也不会阻塞主线程，让 `end` 提前打印出来这正是很多人困惑的根源所在。

手写 sleep —— 用 Promise 包装 setTimeout

 function sleep {
return new Promise => {
console.log;setTimeout => resolve,ms);})，}
// 使用示例
sleep.n => console.log);// 输出：
// Executor 同步运行 → → 2 秒后继续

This pattern lets you create “delay” control flow without blocking main thread.

六、综合示例：同步‑异步混合场景

想要预测下面这段混合代码的输出顺序，却总是抓狂？让我们一步一步拆解：

 console.log;setTimeout => console.log,0);// 宏
Promise.resolve
.n => console.log);// 微
console.log;// 预期输出顺序：① → ④ → ③ → ②

1. 同步日志 `① 同步` 与 `④ 同步` 按书写顺序立即打印；
2. 所有同步代码结束后事件循环检查微任务队列并先执行 `③ 微任务`;
3. 随后取出宏任务 `② 宏任务`;

七、关键要点汇总表格

​

​​

​ ​ ​

​​​

• 理解底层 – 把 JS 看作「唯一经理」管理所有「业务」。
• 掌握 Event Loop – 同步→微任務→宏任務 的固定节奏，是「为什么 setTimeout 后面的代码会先执行」的钥匙。
• 使用 Promise – 用统一容器替代嵌套回调，让异常链式捕获成为可能。
• 实际方法 – 手写 sleep。用 async/await 包装业务流，让异步看起来像同步。

希望这篇文章能帮你彻底打通 JS 异步的任督二脉。如果在实际项目中仍然碰到「复杂依赖」或「难以预测顺序」的问题，不妨先画出「宏‑微‑调用栈」流程图。再用 Promise 链或 async/await 来实现干净可维护的代码结构。祝编码愉快，不过，