在 async 函数中需用 try/finally 显式绑定清理逻辑，确保 await 后资源释放；但未 await 的 rejected Promise 会导致 finally 不执行，应封装资源类、避免 finally 中 await，并配合监控兜底。
在 async 函数中保证资源正确释放，核心是把“清理逻辑”和“错误路径”显式绑定，不能依赖同步 finally 的直觉——因为 await 后的代码可能根本不会执行，而未被捕获的 Promise 拒绝会让整个函数提前退出，跳过后续语句。
用 try/finally 包裹 await 链，但注意它的局限性
try/finally 确实能确保 finally 块在 try 结束后运行（无论是否 throw），但它只对 同步抛出 或 await 内部同步异常 有效。如果 await 的 Promise 被拒绝且没被 catch，finally 仍会执行；但如果整个 async 函数因未处理的 rejection 被丢弃（比如忘记 await 或漏写 catch），则 finally 可能不触发。
- ✅ 正确用法：await 在 try 内，错误被 catch，finally 必然执行
- ⚠️ 风险点：直接调用一个返回 rejected Promise 的 async 函数却不 await 它，finally 不起作用
示例：
复制代码async function loadData() {<br> const resource = acquire();<br> try {<br> const data = await fetch('/api').then(r => r.json());<br> return data;<br> } finally {<br> release(resource); // ✅ 这里总能执行<br> }<br>}
立即学习“Java免费学习笔记（深入）”；
对关键资源使用封装类或自动释放机制
手动管理 release 容易遗漏。更可靠的方式是把资源生命周期和 Promise 生命周期耦合：
- 创建带 .dispose() 或 .close() 方法的资源类，并在 finally 中调用
- 用 async 构造器 + Symbol.asyncDispose（ES2024）支持自动释放（需环境支持）
- 对 fetch / WebSocket / IndexedDB 等，优先使用已封装好 cleanup 的库（如 abortable-fetch、@tanstack/query 的 queryClient.cancelQueries）
例如封装一个可取消的 fetch：
复制代码async function safeFetch(url, signal) {<br> try {<br> const res = await fetch(url, { signal });<br> return await res.json();<br> } catch (err) {<br> if (err.name === 'AbortError') console.log('请求被取消');<br> throw err;<br> }<br>}
避免在 finally 中做异步释放操作
finally 块内不能 await，否则释放逻辑本身会脱离控制流。若释放操作必须异步（如关闭 WebSocket 连接、清空缓存），应：
- 在 finally 中发起释放，但不 await —— 接受“释放可能稍晚完成”，重点是防止泄漏
- 或改用显式生命周期管理：将资源对象设计为“自治”，在构造时注册 cleanup，在 error 或 success 后统一触发
- 对浏览器环境，可结合 AbortController.signal.onabort 处理中断场景
配合全局兜底，监控未释放资源
即便做了上述防护，仍可能有边缘 case 导致资源残留。可在开发期或测试环境加入轻量级监控：
- 维护一个资源计数器（如 openWebSockets.size），在 create 时 ++，release 时 --
- 在 window.beforeunload 或测试 teardown 阶段检查计数器是否归零
- 生产环境可上报长期未关闭的连接 ID，辅助排查
