Promise构造函数是同步执行的，其executor回调在new Promise时立即运行，resolve/reject调用也同步改变状态，但then回调需等待微任务队列。
Promise 构造函数本身是同步执行的，但很多人误以为它“代表异步”，从而把整个 new Promise 当作一个异步操作来理解——这是前端开发中最常见的认知偏差之一。识别这个误区，关键不是背结论，而是看代码执行顺序是否暴露了同步性。
看 executor 是否立即运行
构造函数接收的回调（即 executor）在 new Promise 被调用时**立刻执行**，不等待任何事件循环。只要在里面加一句 console.log，就能验证：
-
写法：
new Promise((resolve) => { console.log('执行了'); resolve(1); }); - 现象：这行 log 会紧接在上一行同步代码之后输出，不会被“卡住”或延后
- 反例误区：如果以为“Promise 就是异步”，就会预期它像 setTimeout 那样延迟执行——但实际它根本没进任务队列
观察 resolve/reject 的调用时机
resolve 或 reject 被调用时，Promise 状态确实会改变，但这个“改变动作”本身是同步完成的（只是后续的 then 回调要等微任务）。重点在于：
- executor 内部调用 resolve(42)，这一步是同步的，状态从 pending → fulfilled 立刻发生
- 但 绑定在 then 上的回调不会此时运行，它要排队等当前同步栈清空
- 常见错觉：看到 then 里打印晚，就以为 resolve 是异步的——其实 resolve 很快，只是 then 的回调被调度得晚
对比 then 的执行位置
把构造函数和 then 放在同一段代码里，输出顺序就是最直接的证据：
-
console.log('A'); new Promise(r => console.log('B')); console.log('C');→ 输出 A → B → C - 加上
.then(() => console.log('D'))后，D 总是排在 C 之后，哪怕 resolve 在 B 行就调用了 - 这个固定顺序（同步代码全跑完，才轮到 D）说明：构造函数参与同步流程，then 不参与
警惕“里面写了异步代码”带来的混淆
很多人在 executor 里写 setTimeout 或 fetch，就自然觉得“Promise 是异步的”。其实：
- setTimeout 是异步，但它属于你写的业务逻辑，跟 Promise 构造函数无关
- new Promise(...) 这一行仍然同步执行，只是它内部启动了一个异步任务
- 类比：
function f() { setTimeout(...); }，调用 f() 是同步的，不能因此说“f 是异步函数”
真正需要异步处理的，从来不是 new Promise 这个动作，而是你如何用 resolve/reject 去衔接异步结果。把 executor 当成一个“同步入口”，把 then 当成“异步出口”，逻辑就清晰了。
