promise链取消靠状态拦截而非abort()，需每个then注册时绑定并检查取消信号；追溯要求每节点唯一id、状态变更同步快照、完整轨迹记录；取消与追溯须互不干扰，且需用户显式释放底层资源。
Promise 链取消不是靠 abort()，而是靠状态拦截
浏览器原生 Promise 不支持中途取消，所谓“链式取消”本质是让后续 then() / catch() 不执行，而非终止已启动的异步任务。手动实现的关键在于：每个 then() 必须注册时就绑定当前 Promise 的取消信号，并在触发前检查状态。不能等 resolve() 后再判断——那时已经晚了。
常见错误是只在异步操作内部做 if (aborted) return，却没阻断 Promise 链本身。结果是任务停了，但 then() 仍被调用（传入 undefined 或默认值），逻辑链断裂但不可控。
实操建议：
- 每个自定义 Promise 实例需维护一个
state字段（"pending"/"fulfilled"/"rejected"/"aborted"） -
then()返回的新 Promise 必须继承上游的取消信号（如闭包捕获父级isAborted函数） - 不依赖全局
AbortController，而是让每个 Promise 持有独立abort()方法，避免跨链污染
全状态追溯必须记录每一步的 value、reason 和 timestamp
“追溯”不是事后查日志，而是在 Promise 状态流转时同步快照。比如 promise.then(f).catch(g) 中，f 抛错后进入 catch，这个跳转必须被记录为一条带时间戳、来源节点 ID、输入值、输出值、错误堆栈的轨迹。
容易踩的坑是只存最终结果，导致无法还原“为什么 then() 没触发”或“catch() 接收到的到底是不是原始错误”。例如：Promise.resolve(42).then(() => { throw 'oops' }).catch(console.log)，若不记录中间 then 的执行与失败，就无法区分是 then 内部抛错，还是上游 resolve 传入的就是 Error 实例。
实操建议：
- 每个 Promise 节点生成唯一
id（如Symbol()或递增数字），所有轨迹事件都关联该 ID - 状态变更时调用
record({ type: "resolved", value, timestamp: Date.now(), from: prevId }) - 提供
getTrace()方法返回按时间序排列的数组，含type（"created"/"resolved"/"rejected"/"aborted"）、value、reason、timestamp、from
链式取消必须穿透嵌套 Promise.resolve() 和 async/await
用户写 async function foo() { return await bar(); }，实际等价于 return bar().then(v => Promise.resolve(v))。如果只拦截顶层 then()，内层 Promise.resolve(v) 会绕过取消逻辑，导致链恢复执行。
性能影响明显：每层 then() 都要检查取消状态，但不能用 setTimeout 延迟判断（破坏时序），也不能每次检查都遍历整个祖先链（O(n) 开销）。正确做法是让每个子 Promise 在创建时就继承父级的 isAborted 函数，并缓存该函数引用。
实操建议：
- 禁止直接返回
new Promise(...)，一律用引擎提供的Promiselike.resolve()/Promiselike.reject()构造，确保状态可追溯 -
async函数需被wrapAsync()包裹，使其返回的 Promise 绑定当前上下文的取消信号 - 对
Promise.all([...])这类聚合操作，任一子项aborted应触发整体aborted，而非等待全部 settle
abort() 调用后，已 pending 的回调必须被清空且不可恢复
很多实现把 abort() 简单等同于 “设 state = "aborted"”，但忘了清理已注册但尚未执行的 onFulfilled / onRejected 回调队列。结果是稍后某个微任务中这些回调仍被调用，传入 undefined 或默认值，造成逻辑错乱。
更隐蔽的问题是：如果用户在 then() 回调里又调用了 abort()，而此时 Promise 已处于 "aborted" 状态，不应再触发重复清理或报错，应静默忽略。
实操建议：
- 用 WeakMap 存储每个 Promise 实例的回调队列，
abort()时清空并置为null - 所有
then()注册逻辑需前置检查if (this.state === "aborted") { queueMicrotask(() => onRejected?.(new Error("Aborted"))); return; } -
abort()方法自身需幂等：首次调用后，后续调用不改变状态、不重复清理、不抛异常
真正难的不是实现取消或追溯，而是让这两者在 Promise 规范的约束下不互相干扰——取消不能污染状态快照，追溯不能拖慢链式执行。最易被忽略的是异步资源（如 fetch、setTimeout）的主动释放：引擎能拦住 Promise 链，但拦不住底层网络请求或定时器，这部分必须由使用者显式配合，比如在 onAbort 回调里调用 controller.abort() 或 clearTimeout(id)。
