前几天随手敲了一段最简单的定时器代码。本以为是再基础但是的知识点，闭着眼都能猜对输出结果。结果代码一跑，控制台的打印顺序直接推翻了我的固有认知，当场懵了。

说到我第一反应是，代码从上到下逐行执行。顺序肯定是 start → → end。可实际运行后才发现根本不是这么回事，这正好暴露了我对 JS 同步、异步与 Promise 的认知盲区。

至于入门演示，最小定时器代码

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

实际输出顺序：

start
end
// 等待 1 秒后
timeout

从底层原理来看，进程、线程与单线程模型

进程 vs 线程

进程 = 公司董事长负责分配内存、资源等全局事务；线程 = 执行具体工作的经理真正跑代码、处理任务。

与 Java、C++ 等支持多线程的语言不同，JS 从设计之初就被限定为单线程——整个进程里只有一个主线程在工作。这种设计避免了多线程资源抢占和 DOM 冲突，让页面交互更可靠。其实，

事件循环解决耗时任务卡死的问题

1. 主线程全速执行同步代码。
2. 遇到耗时的异步任务，立即把它们放入“任务队列”。
3. 当主线程空闲时从队列中按顺序取出任务执行。

纯同步示例——验证单线程顺序一致性

// 纯同步代码，单线程按顺序逐行执行
let a = 1;let b = 2，let c = 3;怎么说呢，console.log;// 直接输出 6

Pain point：一旦在项目中混入异步调用。如果不清楚事件循环的排队机制，就会出现「先打印后执行」的怪现象，导致 UI 卡顿或业务逻辑错位。

从回调地狱到 Promise：标准化异步流程

实际业务往往需要先获取列表，再根据每条记录发起二次请求。不过，如果继续使用嵌套回调，会迅速变成“回调地狱”。ES6 为此提供了 Promise让异步流程可链式组织。

Hello Promise —— 基础写法与主要规则拆解

// 创建 Promise 实例
const p = new Promise => {
// 耗时任务
setTimeout => {
// resolve;// 成功分支
reject;// 失败分支
},1000);})，// 查看原型链
console.log;
// 链式处理结果
p.n(data => {
console.log;console.log，})
.catch(err => {
console.log;console.log，})
.finally => {
console.log;})，

• 执行器函数 : 在实例化时立即同步执行。
• resolve / reject: 用来标记任务成功或失败。并将结果分别传递给 .n/.catch.
• .finally: 不论状态如何都会执行，用于统一收尾。

PROMISE 与 FETCH 的关联示例

Pain point："start" 和 "end" 为什么先打印，而不是等接口返回后才出现？这正是事件循环把 fetch 返回的 Promise 放入微任务队列导致的现象。

Pitfalls——别再被表象误导！

Pitfall 1：误以为 Promise 构造器内部代码是异步的

I once wrote a “sleep” helper:

function sleep {
const p = new Promise => {
// 看似“延迟”，但下面这行是同步执行的！console.log，setTimeout => {
resolve;},t)，});return p，}
sleep.n => {
console.log;})，

The console prints “同步日志 - 构造阶段” **immediately**,n after two seconds prints “2 秒后执行”。The key insight:

• The executor runs **synchronously** when Promise is created.
• The only asynchronous part is whatever you manually schedule inside .

Pitfall 2：误认为 .finally`只在成功时触发

I initially believed .finally` was a “success‑only” hook. Testing proved orwise:

new Promise => reject)
.catch)
.finally => console.log);

The message in .finally

Synsis – 主要要点速记