原生 Promise 无法满足静态状态快照需求，因其状态被封装在 C++ 层、JavaScript 无法访问，且 resolved/rejected 后不可观测；可行方案是从头实现兼容 Promise A+ 的容器，暴露可读状态字段并接管调度逻辑。
为什么原生 Promise 无法满足静态状态快照需求
原生 Promise 实例一旦 resolved 或 rejected，其内部状态就不可观测、不可导出——你拿不到它“此刻是否 pending”“当时传入的 value 是什么”这类信息。调试异步流、做时间旅行式回放、或在 SSR 中序列化中间态时，这会直接卡死。关键不是“不能用”，而是“状态被封装在 C++ 层，JavaScript 层无访问入口”。
实操建议：
- 不要尝试 patch
Promise.prototype.then来劫持状态——微任务队列（queueMicrotask）和引擎调度耦合太深，劫持后极易破坏then链的执行顺序 - 避免继承原生
Promise（class MyPromise extends Promise）——子类构造器必须调用super()，但无法控制初始状态，且Promise.resolve()等静态方法仍返回原生实例 - 真正可行的路径是：从头实现一个兼容 Promise A+ 规范的容器，把状态字段（
state、value、reason）暴露为只读属性，并接管 then/catch 的回调注册与调度逻辑
如何用 queueMicrotask 实现可预测的微任务调度
原生 Promise 的 then 回调由引擎隐式推入微任务队列，你无法插入、拦截或延迟它们。而手动容器必须显式使用 queueMicrotask，否则会退化成宏任务（如 setTimeout(fn, 0)），破坏 Promise 语义。
实操建议：
- 所有
onFulfilled/onRejected回调，必须包裹在queueMicrotask(() => {...})中触发，哪怕当前状态已是 fulfilled —— 这是 Promise A+ 要求的“异步执行保证” - 注意 Node.js 11+ 和现代浏览器才默认支持
queueMicrotask；若需兼容旧环境，可用Promise.resolve().then()降级，但要确保不创建新 Promise 实例（避免无限递归） - 多个
then注册时，回调应按注册顺序入队，而非执行顺序——这意味着你要维护一个callbacks数组，并在状态变更时遍历调用，每个调用都走一次queueMicrotask
静态状态快照的关键字段设计与冻结策略
快照能力不等于“能读属性”，而是要求状态在任意时刻可安全序列化且不随后续操作突变。比如你调用 container.snapshot() 后，即使容器内部又 resolve 了，快照对象也不该改变。
实操建议：
- 核心字段必须是
state: 'pending' | 'fulfilled' | 'rejected'、value: any、reason: any，且仅在内部方法（如resolve()）中修改 - 对外暴露的
snapshot()方法应返回新对象：{ state, value: state === 'fulfilled' ? structuredClone(value) : undefined, reason: state === 'rejected' ? structuredClone(reason) : undefined }—— 用structuredClone避免引用泄漏，但要注意它不支持 function/undefined/symbol，需提前过滤或标记 - 不要对实例本身调用
Object.freeze(this)—— 这会阻止后续状态更新；只需确保snapshot()返回的对象是浅冻结的（Object.freeze({...})）即可
兼容性陷阱：链式调用与错误冒泡怎么不出错
手动实现时最容易翻车的是 then 返回的新 Promise 如何与父容器状态联动。原生 Promise 的“返回值穿透”和“错误自动 reject 新 Promise”逻辑，稍有偏差就会导致链断裂或静默失败。
实操建议：
-
then(onFulfilled, onRejected)必须返回一个新容器实例（非this），且该实例的初始状态为 pending；它的 resolve/reject 由onFulfilled执行结果决定——如果返回 Promise，则需then它；如果抛错，则新容器 reject 该错误 - 错误冒泡必须严格遵循：若
onFulfilled抛错，且未提供onRejected，则错误应传递给下一个catch或链尾的 rejection handler；这要求你在注册回调时，把onRejected存入同一个队列，并在onFulfilled抛错时跳过它、直接触发onRejected - 测试时重点验证：
new Container(resolve => resolve()).then(() => { throw 'err' }).catch(e => console.log(e))是否输出'err'—— 很多手写实现在这里漏掉 try/catch 包裹onFulfilled
真正的难点不在“怎么让 then 执行”，而在“怎么让每一次执行都像原生 Promise 那样不可感知地嵌套、转发、截断”。状态快照只是表象，背后是对 Promise A+ 规范里 25 条执行细则的逐条对齐——尤其是“then must return a promise”和“onFulfilled/onRejected must be called asynchronously”这两条，错一条，整个链就不可靠。
