Promise构造函数中executor必须同步执行，否则违反Promises/A+规范；then必须返回新Promise并正确处理状态流转、微任务调度及thenable递归展开。
Promise 构造函数里必须同步执行 executor
这是 Promises/A+ 最容易被忽略的硬性要求：传入 new Promise(executor) 的 executor 函数，必须**立即、同步调用**，不能 defer、不能 setTimeout、不能 nextTick。否则后续所有状态流转（pending → fulfilled/rejected）都会错位，导致 then 链无法按预期收集回调。
常见错误是把 executor 包在 setTimeout(() => { ... }, 0) 里“模拟异步”，这直接违反规范，测试套件（如 promises-aplus-tests）会立刻报 Test failed: promise created in non-pending state。
- 正确做法：在构造函数内部直接
executor(resolve, reject) - resolve/reject 必须是函数，且只能调用一次（多次调用应静默忽略）
- executor 抛出异常时，等价于调用
reject(e)，需 try/catch 包裹
then 方法必须返回新 Promise，且支持链式调用
then 不是修改原 Promise，而是返回一个全新的 Promise 实例——这是自动状态流转的核心机制。如果返回的是普通值（比如数字、字符串），新 Promise 状态为 fulfilled；如果返回的是另一个 Promise（或 thenable），新 Promise 状态要**跟随它**（即“穿透”）。
实现上关键点在于：无论当前 Promise 处于 pending、fulfilled 还是 rejected，then 都必须返回 Promise，并把传入的 onFulfilled/onRejected 回调存入对应队列（或立即执行）。注意：不能在 then 内部直接 resolve 当前 Promise，那会破坏链式结构。
- pending 状态：将回调推入
onFulfilledQueue/onRejectedQueue - fulfilled 状态：用微任务（如
queueMicrotask或Promise.resolve().then）延迟执行onFulfilled(value) - rejected 状态：同理，用微任务执行
onRejected(reason) - 返回的新 Promise 的 resolve/reject 必须由执行结果决定，不是由原 Promise 的状态决定
状态只能从 pending → fulfilled 或 pending → rejected，不可逆
Promise 的 state 字段一旦从 "pending" 变为 "fulfilled" 或 "rejected"，就再也不能更改。这是自动流转不混乱的前提。很多手写库在这里出 bug：比如 resolve 后又调用了 reject，或者在不同分支重复 resolve。
典型表现是测试时出现 TypeError: Cannot resolve a resolved promise 类似错误（虽然规范没强制抛错，但必须静默忽略后续调用）。
- 建议用闭包变量
state+value/reason存储，而非 this.state - resolve 和 reject 函数开头加守卫：
if (state !== "pending") return - 不要在 resolve/reject 内部再调用对方，也不要在 executor 外部暴露 resolve/reject 引用
处理 thenable 对象时必须遵守“可递归展开”规则
当 resolve 的参数是一个 thenable（即有 .then 方法的对象），Promise/A+ 要求你**尝试调用它的 .then**，并根据其执行结果决定新 Promise 的状态。这不是可选项，是必须递归展开的逻辑。
错误做法是直接把 thenable 当作普通值 resolve，这样会导致 thenable 的异步行为被跳过，链式调用中断。正确做法是用 try/catch 安全调用 thenable.then，并传入自己的 resolve/reject —— 这就是“同构”和“信任传递”的本质。
- 先判断
val !== null && typeof val === "object" || typeof val === "function" - 再取
then = val.then，确认是函数才进入 thenable 分支 - 调用
then.call(val, resolve, reject)，并确保只调用一次 - 如果调用过程抛错，立即
reject(e)
最难缠的其实是微任务调度时机和 thenable 的嵌套深度：resolve 一个带 then 的对象，它内部 resolve 的又是个 thenable……这种层层穿透必须靠递归+微任务保证不爆栈也不丢任务。写到这儿，基本就不是“手写”而是“重造轮子”了。
