promise 的 executor 函数在创建时立即同步执行，resolve/reject 本身同步调用但仅标记状态并调度微任务，then/catch 回调作为微任务在当前宏任务结束后执行。
Promise 的 executor 函数在 Promise 创建时**立即同步执行**，不等待事件循环的任何阶段，这是理解其行为的关键起点。
executor 是同步调用的
当你 new Promise(fn) 时，传入的 executor 函数（即 fn）会**立刻被调用**，不是放入微任务队列，也不是延迟到下一轮事件循环。它和普通函数调用一样，在当前执行栈中同步运行。
- 即使 Promise 内部有 resolve 或 reject，它们也只影响后续 then/catch 的触发时机，不影响 executor 本身的执行时机
- 如果 executor 抛出错误，Promise 会以该错误为 reason 被拒绝，等价于在内部调用了 reject(error)
- 示例：new Promise(() => { console.log('立即打印') }) —— 这行代码执行完，“立即打印”就输出了，不等任何异步操作
resolve/reject 不是异步操作
resolve 和 reject 本身是同步函数，但它们的作用是**标记 Promise 状态并调度微任务**：一旦状态改变，then/catch 回调会被加入微任务队列，等待当前同步代码执行完毕后，在本轮事件循环结束前执行。
- 调用 resolve(42) 不会立刻执行 then 回调，而是把回调排队到微任务队列
- 如果 Promise 已经处于 fulfilled 或 rejected 状态，后续再调用 resolve/reject 会被忽略（状态不可逆）
- 注意：resolve 一个 Promise（如 resolve(Promise.resolve(1))）会触发“Promise 解析过程”，可能引发额外的微任务链
与事件循环各阶段的关系
Promise 的 executor 属于**同步代码**，运行在当前宏任务（如 script、setTimeout 回调、事件处理函数）的执行中；而 then/catch 回调属于**微任务**，在当前宏任务结束后、下一个宏任务开始前执行。
- 宏任务（如 setTimeout、setInterval、I/O）→ 同步代码（含 executor）→ 微任务（then/catch、queueMicrotask）→ 下一个宏任务
- 这意味着：executor 中的同步代码一定早于所有微任务执行；微任务一定早于下一个宏任务执行
- 常见陷阱：误以为 new Promise(() => setTimeout(resolve, 0)) 中的 resolve 是“马上执行”，其实 setTimeout 是宏任务，executor 仍是同步执行，只是 resolve 被延迟调用了
实际调试建议
判断一段 Promise 相关代码的执行顺序，可抓住两个锚点：executor 执行时刻（同步）、then 回调入队时刻（微任务）。用 console.log + 注释标记执行位置，比单纯看 Promise 链更可靠。
- 在 executor 里加 log，它总在最前面输出
- 在 then 里加 log，它总在当前脚本或宏任务末尾、下个 setTimeout 之前输出
- 配合 queueMicrotask 对照验证：它的执行时机与 then 回调一致
