async/await 与 try-finally 结合是 javascript 中保障资源可靠释放的核心组合，要求资源声明在 try 外、finally 中 await 异步清理、主动响应取消并重抛错误，同时覆盖事件监听器、定时器等隐式资源。
async/await 与 try-finally 结合，是 JavaScript 中保障资源可靠释放的核心组合。它不依赖 Promise 链的写法，也不靠开发者手动记住“收尾”，而是利用语言机制强制执行清理逻辑——只要代码进了 try 块，finally 就一定会运行，哪怕 await 被取消、抛出错误，甚至函数提前 return。
资源声明必须在 try 外
这是容易出错的第一步。如果把资源（比如打开的连接、定时器 ID、加载状态标识）声明在 try 块内，一旦异常提前跳出，finally 就访问不到它，清理就失效。
- ✅ 正确：let conn = await createConnection(); try { ... } finally { await conn.close(); }
- ❌ 错误：try { let conn = await createConnection(); ... } finally { await conn.close(); } // conn 未定义
finally 中必须用 await 执行异步清理
资源关闭操作（如 fetch 的 AbortController、WebSocket.close()、自定义的 dispose() 方法）往往是异步的。直接调用而不 await，会导致清理逻辑被“甩”在后面，实际还没完成函数就结束了。
- ✅ 正确：finally { await db.disconnect(); await fileHandle.close(); }
- ❌ 错误：finally { db.disconnect(); fileHandle.close(); } // 只是发起关闭，没等完成
要主动响应取消并保留取消信号
当一个 async 函数被外部 cancel（例如 AbortSignal.abort() 触发），await 点会抛出 AbortError 或 CancelledError。此时仅靠 finally 不够——你需要在 try 中捕获它，在清理后重新 throw，否则上层无法感知任务已被取消。
- 在 try 中 await 可能被中断的操作（如 longPolling()、stream.read()）
- 用 catch 捕获 AbortError，做必要清理（如清除监听、释放 buffer）
- 清理完成后 re-throw，确保取消状态不被吞掉
- finally 再补一层兜底：比如关闭底层 socket、重置全局锁标志
前端常见资源类型不能只盯“连接”
除了 fetch、WebSocket 这类显式资源，还有大量隐式但需手动清理的“软资源”：
- 事件监听器：addEventListener 后记得 removeEventListener，尤其在组件卸载或切换时
- 定时器：setTimeout/setInterval 返回的 ID，必须 clearTimeout/clearInterval
- 动画帧：requestAnimationFrame 返回的 handle，要用 cancelAnimationFrame 清除
- 全局状态：如 loading = true，务必在 finally 中设回 false，避免 UI 卡死
这套模式不是银弹，但它把“可能忘掉”的事情变成“不得不做”。写一次 try-finally，比在每个 catch 和正常路径里重复写 cleanup 更安全，也比靠文档或记忆更可靠。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
