1. 一次异步崩溃引出的问题做 N-API 扩展时JS 侧调用一个异步 APIC 这边起工作线程去调第三方业务 SDK通常是另一个.dll或.soSDK 在自己的后台线程里干活完成后通过回调把结果传回 JS。代码写起来很自然代码语言cppAI代码解释class PageController : public std::enable_shared_from_thisPageController { public: void loadResource(const std::string resId) { sdk-loadAsync(resId, [weakSelf weak_from_this()](Result result) { auto self weakSelf.lock(); if (!self) { return; } self-onLoaded(result); }); } void onLoaded(Result result) { /* 更新 UI */ } };用weak_from_this代替this捕获。this悬垂的问题确实解决了。但操作不只涉及this——SDK 内部还持有其他对象的引用那些对象也可能在回调执行前析构。weak_ptr能守住自己守不住 SDK 引用的其他对象。前端类比组件卸载时可以清掉自己的定时器但清不掉全局事件总线上注册的回调。weak_ptr同理——管得了自己的析构管不了 SDK 内部还握着什么。单个对象的生命周期已经管住了但一个异步操作涉及多个对象的协同这部分还没有着落。异步操作的生命周期管理要回答两个问题对象还活着吗操作还在进行吗。2. 对象还活着吗异步操作有个时间差发起操作的对象可能在回调执行前析构。比如用户在资源加载完成前就离开了页面PageController析构了但 SDK 的回调还在排队。回调执行时访问已析构的对象就是 UAF。前端类比useEffect里发了个请求组件卸载了请求才回来。不处理就会操作已卸载的组件。JS 里有 GC 兜底组件卸载后引用还在不会立刻出事。C 里对象析构就是析构了指针指向废内存。weak_ptr lock就是这个问题的解法。用一个不持有所有权的弱引用观察对象回调执行前先检查对象还在不在代码语言cppAI代码解释class PageController : public std::enable_shared_from_thisPageController { public: void refreshUI() { /* ... */ } void startDelayedTask(std::vectorstd::functionvoid() queue) { std::weak_ptrPageController weakSelf shared_from_this(); queue.push_back([weakSelf]() { auto self weakSelf.lock(); if (!self) { return; } // 对象已销毁安全跳过 self-refreshUI(); // 对象还活着安全调用 }); } };创建对象、注册回调、对象析构后再执行回调。lock()失败时回调安全退出不会访问废内存。但光守住对象还不够。对象还活着不代表操作只执行一次。3. 操作只结算一次SDK 有 bug 时可能对同一个操作回调两次。第一次回调 resolve 了 Promise第二次又来 resolve行为未定义。更隐蔽的是如果回调里有delete操作两次delete同一个指针就是 double-free。根因是异步操作没有一个「已完结」的标记。回调来了就执行不检查这个操作是不是已经结算过。最直接的想法是给每个操作加一个 bool 标记。但真实业务里一个模块可能同时有几十个 pending 操作分布在多个线程散落的 bool 标记不好管。更可靠的做法是集中管理把所有 pending 操作放进一张表每个操作分配一个唯一 id回调来了用 id 去表里认领。认领成功就从表里删除第二次认领时找不到条目直接失败。代码语言cppAI代码解释class SimpleRegistry { public: uint64_t add(std::string name) { uint64_t id next_id_; std::lock_guardstd::mutex lock(mu_); entries_[id] name; return id; } bool claim(uint64_t id, std::string outName) { std::lock_guardstd::mutex lock(mu_); auto it entries_.find(id); if (it entries_.end()) return false; // 已被认领 outName it-second; entries_.erase(it); // 认领后删除 return true; } // ... };add发起操作时调往表里插一条拿到唯一 id。claim回调进来时调用 id 查表找到就取出并删除返回 true找不到已被认领过返回 false。所有操作都加了锁多线程安全。实际使用流程是这样的发起异步操作时调add拿到op_id存进回调上下文。SDK 回调进来时用op_id调claim第一次成功走 resolve 逻辑SDK bug 导致的第二次回调claim返回 false直接跳过。对照一下就很清楚代码语言cppAI代码解释// 首次回调 registry.claim(op, name); // → 成功走 resolve // SDK bug 导致第二次回调 registry.claim(op, name); // → 失败安全跳过这就是 once 语义。Registry 双重回调防御前端类比一个 Promise 只能 resolve 一次。你可以在 resolve 前放一个标志位第二次调直接忽略。Registry 的claim就是把这件事做到了操作级别。weak_ptr::lock管的是对象生命周期Registry 的claim管的是操作生命周期。两层配合异步回调才不会因重复触发或悬空引用而出事。4. 退出时批量回收进程退出时可能还有一堆异步操作没完成。这些操作的 Promise 还在 pendingJS 侧的await会永远卡住。更麻烦的是SDK 的后台线程可能还在跑回调进来时napi_env已经销毁了再访问就崩。退出时不能直接走得先把所有 pending 操作统一结算掉。Registry 已经有claim再补一个claimAll就能批量回收代码语言cppAI代码解释void claimAll(std::vectorstd::pairuint64_t, std::string out) { std::lock_guardstd::mutex lock(mu_); for (auto [id, name] : entries_) { out.emplace_back(id, name); } entries_.clear(); }退出时批量取出所有 pending 操作逐个 reject告诉 JS 侧环境正在关闭。这和 React 的useEffectcleanup 是一个思路组件或进程卸载时把所有未完成的异步操作统一清理不能留悬空回调。这里有个顺序问题。如果通道已经被abort投递了但还没执行的 lambda 不会跑了lambda 里new的对象会泄漏。所以abort之前要先claimAll把 pending 操作回收掉让对应的清理逻辑跑完再关闭通道。顺序不能反。