try-catch无法捕获资源占有异常，因其仅处理同步错误或await reject的异常；资源泄漏源于逻辑遗漏，须用finally或生命周期管理确保确定性释放。
try-catch 本身不直接处理“资源占有异常”，比如内存泄漏、文件句柄未释放、数据库连接未关闭、定时器未清除等。它只能捕获**同步抛出的错误**或**await 等待的 Promise 被 reject 并显式 throw 的异常**。而资源占有问题通常不是“抛异常”导致的，而是**逻辑遗漏或生命周期管理缺失**引发的隐性风险。
哪些资源问题 try-catch 根本捕不到
以下情况即使加了 try-catch 也完全无效：
- 忘记调用 fs.close() 或 connection.end()，连接/句柄持续占用
- setInterval 启动后未在组件卸载或任务结束时 clearInterval
- addEventListener 绑定后未对应 removeEventListener，造成事件监听器堆积
- 异步操作中创建了大对象（如巨型数组、Base64 图片），但未在错误路径中主动释放引用
真正该做的：用 finally 或显式清理逻辑兜底
资源释放必须是确定性行为，不能依赖“有没有出错”。正确做法是在 finally 块中执行清理，或封装成带生命周期控制的工具函数：
- 对数据库连接：用 try → await query → finally → connection.release()
- 对文件读写：用 try → await fs.promises.open → ... → finally → fd.close()
- 对定时器：定义变量保存 timer ID，在 finally 或 catch + return 后统一 clearTimeout(timer)
- 对事件监听：在组件 unmount / 函数退出前，确保调用移除逻辑（推荐用 AbortController 配合 addEventListener）
async 函数里怎么写才安全
以读取并解析一个远程 JSON 文件为例：
- ❌ 错误写法（无清理、无超时、无 reject 检查）：
const res = await fetch(url);
return res.json(); - ✅ 改进写法（含超时、状态检查、finally 清理）：
const controller = new AbortController();
setTimeout(() => controller.abort(), 8000);
try {
const res = await fetch(url, { signal: controller.signal });
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return await res.json();
} finally {
controller.abort(); // 确保释放信号
}
补充建议：用工具链提前发现隐患
靠人工写 finally 容易遗漏。可结合：
- ESLint 规则：no-unused-vars（防未用 timer 变量）、require-atomic-updates（防竞态更新）
- Node.js 中启用 --trace-warnings 查看未处理的 Promise rejection
- 前端使用 Performance.memory（需开启 flag）或 Chrome DevTools 的 Memory 面板定期快照比对
- 关键服务层封装“资源自动回收”包装器，例如：
withDBConnection(async (conn) => { /* 自动 conn.release() */ })
