北京
一个请求处理到一半报错，数据库连接关了，Redis 锁却没释放。文件句柄还挂着，直到连接池耗尽、磁盘配额告警，几小时后才有人发现。这类资源泄漏在服务端并不少见，问题往往出在清理链条被上游错误打断。
多数团队会写嵌套的 try-finally，把每个资源包一层。三个资源以内还能看，再多就难读了。更麻烦的是，清理代码本身一旦抛错，后面的资源就不会被释放，释放顺序也变成隐式的、脆弱的。
一个栈，管住所有资源
TypeScript 的 AsyncDisposableStack 提供了显式的多资源清理协调。它用一个栈追踪每个可释放对象，保证逆序清理，即使某个清理操作失败也不影响其余资源。入口只有一行：await using stack = new AsyncDisposableStack()。
它提供三种注册方式，对应不同场景：
- adopt()：接收一个资源值和一个清理函数，原样返回资源，适合没有实现 Symbol.asyncDispose 的对象，比如归还连接池、释放锁。
- use()：直接注册已实现 AsyncDisposable 的对象，委托给它自己的 Symbol.asyncDispose 实现。
- defer()：把任意异步工作推迟到清理阶段，不绑定具体资源值，适合依赖闭包状态的清理，或无论资源是否分配成功都要执行的操作。
顺序是逆序，错误不丢
清理严格遵循后进先出。先注册数据库连接，再注册 Redis 锁，最后注册文件句柄，释放时就是文件句柄先关、锁第二、连接最后归还。这个顺序有意义：后注册的资源在清理时，往往还需要先注册的资源仍然可用。
清理过程中出现的错误不会互相覆盖，而是聚合成一条 SuppressedError 链，保留每一次失败的上下文，而不是把前面的错误藏起来。
还有一个 move() 方法，把已注册的资源从一个栈整体转移到另一个栈，源栈随即进入已释放状态。这让函数可以构建一组资源，再把清理责任交还给调用方。
栈上还有个 disposed 属性，标记清理序列是否已执行。一旦清理完成，再尝试注册新资源会抛 ReferenceError，防止清理开始后还有人往里塞东西。
请求级资源管理的典型场景
一个处理上传文件的 API 端点能说明问题：写元数据需要数据库事务，防止同一文件并发处理需要 Redis 锁，暂存上传需要临时文件句柄。三个资源必须在请求无论成功还是失败时都原子释放。
AsyncDisposableStack 的价值正体现在这种请求级资源管理里——数据库连接、分布式锁、文件句柄，要么一起释放，要么按确定的顺序释放，不留下半拉子状态。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
