题目与范围
处理器会获得同步与异步资源，生命周期必须在代码块边界结束。请使用 JavaScript 显式资源管理协议设计安全封装，并说明构造、正文执行或清理失败时的行为。回答要区分语法与运行时支持；TypeScript 5.2 可以检查相关语法，但生产可用性仍取决于目标引擎和转译方案。
核心能力是资源生命周期和失败安全实现，因此归入 coding。
面试官考察什么
第一，能否用 [Symbol.dispose]() 表示同步清理，用 [Symbol.asyncDispose]() 表示必须等待的异步清理？
第二，是否理解 using 与 await using 是有作用域的声明？控制流离开代码块时会清理，包括抛出异常；长期存在的顶层作用域通常不合适。
第三，能否说明释放顺序？资源按声明的逆序释放，因此有依赖关系时应先声明依赖，再声明依赖它的资源。
第四，能否处理错误？正文错误和清理错误可能同时发生，不能让清理错误悄悄覆盖主错误。
第五，能否提供兼容方案？目标运行时不支持协议时，需要特性检测、编译转换或等价的 try/finally 适配器。
先澄清的问题
- 生产使用哪些 Node.js 或浏览器版本，是否允许转译？
- 哪些资源是同步清理，哪些清理函数返回 Promise？
- 取消时必须立即关闭，还是允许当前操作完成？
- 资源之间是否存在依赖，后释放的资源是否依赖先释放的资源？
- 清理错误应失败请求、记录日志，还是附加到主错误？
- 可以使用 DisposableStack，还是只能实现基础符号？
30 秒回答框架
“我会为每个资源实现明确的释放协议，把声明放在拥有它的最小代码块中；异步清理使用 await using。依赖资源后声明，利用逆序释放保证顺序安全；测试成功、正文异常、获取失败和取消，并保留正文与清理错误。发布前验证运行时支持，或转译成等价的 try/finally；TypeScript 的语法支持不等于运行时已经实现。”
分步作答
第一步：定义窄职责释放协议
把获取和清理放在同一资源封装中。同步资源实现 [Symbol.dispose]()；异步资源实现 [Symbol.asyncDispose]()，并使用 await using 让退出路径等待清理完成。
class FileLease {
constructor(private readonly fd: number) {}
[Symbol.dispose]() { closeFile(this.fd) }
}
class AsyncLockLease {
constructor(private readonly release: () => Promise<void>) {}
async [Symbol.asyncDispose]() { await this.release() }
}如果调用者也可能主动取消，释放函数应具备幂等性。[Symbol.dispose]() 不应返回 Promise；需要等待时使用异步协议。
第二步：缩小生命周期代码块
进入拥有资源的代码块后再获取资源，避免把 using 变量存入更长寿命的对象；它绑定的是词法作用域，不是垃圾回收时间。
async function handle() {
{
using file = openFileLease()
await using lock = await acquireLockLease()
await writeWithLock(file, lock)
}
}锁在文件之后声明，因此先释放锁，再关闭文件。正文抛出异常时，两条退出路径仍会执行。
第三步：处理获取失败与取消
资源一旦获取成功就要纳入清理范围。后续获取失败时，已获取资源仍必须释放。把取消信号连接到业务操作，但不要让取消绕过作用域清理。
第四步：保留完整失败信息
分别测试正文异常和清理异常，再测试两者同时发生。日志应包含主错误和被抑制的清理错误；手写 try/finally 适配器时也不能覆盖正文错误。
第五步：规划兼容性
检查实际部署引擎，而不是只看 TypeScript 编译器。缺少原生语法或符号时，可使用编译转换、经过审核的 polyfill，或应用层 try/finally 适配器，并保持逆序、幂等、等待和错误链语义一致。
第六步：测试生命周期边界
用可控假资源记录获取与释放事件，覆盖正常返回、正文抛错、第二次获取失败、工作中止、释放失败和重复释放。断言事件顺序，并确认 Promise 结束后没有资源遗留。
示例回答
“我把每个句柄建模为可释放租约：同步句柄实现 [Symbol.dispose]，异步释放实现 [Symbol.asyncDispose]。资源放在最小拥有代码块中，锁使用 await using，并在文件之后声明，这样逆序释放时先解锁再关文件。返回、异常和取消都会离开作用域并触发清理。
我会测试获取失败、正文失败、清理失败及组合情况，保留主错误和被抑制信息，并验证幂等与取消行为。最后检查生产引擎；TypeScript 5.2 的支持只是编译期能力。若运行时不支持，就转译或使用语义相同的 try/finally 适配器。”
常见错误
- 把资源放在长期作用域 → 清理延迟 → 绑定到最小拥有代码块。
- 用
using处理异步清理 → Promise 可能未等待 → 使用异步协议与await using。 - 先声明依赖资源 → 逆序释放过早关闭依赖 → 依赖先声明，使用者后声明。
- 把编译器支持当成运行时支持 → 线上解析或符号查找失败 → 检查引擎并准备降级。
- 用清理错误覆盖正文错误 → 根因丢失 → 保留主错误和清理错误链。
- 允许重复释放 → 资源状态损坏 → 保证幂等或集中所有权。
- 只测成功路径 → 失败路径泄漏 → 覆盖获取、正文、取消和清理错误。
追问
追问 1：using 会替代垃圾回收吗？
不会。它为句柄、锁等资源提供确定性的作用域清理；内存回收仍由运行时负责。
追问 2：为什么逆序释放？
后声明的资源通常依赖先声明的资源，逆序能先释放使用者，再关闭依赖。
追问 3：什么时候需要异步清理？
释放本身需要等待时，例如刷新缓冲区或向远程协调器归还租约，就应使用异步协议。
追问 4：正文与清理都失败怎么办？
保留正文错误为主错误，并通过运行时抑制错误机制或显式错误链暴露清理失败。
追问 5：可以手动释放吗？
可以，但要让释放幂等，或明确所有权，防止作用域退出时二次释放。
追问 6：没有原生支持如何降级？
使用编译转换、经过审核的 polyfill 或 try/finally 适配器，并保持逆序、等待、幂等和错误链语义。