局部变量能否被安全回收取决于是否还有活跃引用，而非是否发生异常；try-catch不阻止回收，仅新增作用域链节点；let/const声明的变量作用域受限，var提升至函数作用域，catch参数仅块内有效；真正导致驻留的是闭包、全局赋值或异步持有等隐式引用。
块级作用域内发生异常时，局部变量能否被安全回收，关键不在于“是否发生异常”，而在于“变量是否还被引用”——JavaScript的垃圾回收机制只看引用关系，不看代码是否执行出错。
try-catch本身不会阻止变量回收
catch块会创建一个临时的词法环境（含错误对象），但它只是**新增作用域链节点**，不是变量“驻留区”。只要变量没被闭包捕获、没被全局或外层作用域引用，即使在try或catch中声明，执行结束后就会进入可回收状态。
- 用let/const在try块内声明的变量，作用域仅限该块，catch和finally中根本访问不到，自然不会延长生命周期
- 用var声明的变量会提升到函数作用域顶层，只要函数执行结束且无外部引用，也会被回收
- catch参数（如
catch(e)）是块级绑定，仅在catch内部有效，退出后e就不可访问，引用消失
真正影响回收的是引用是否断开
变量是否被回收，取决于它所指向的值是否还有活跃引用。常见“意外驻留”场景：
- 在catch中把错误对象或局部变量赋给全局变量或外层闭包，比如
window.lastError = e或outerRef = someObj - 局部对象被事件监听器、定时器、Promise回调等异步逻辑持有（即使抛错，回调未执行完，引用仍在）
- try块内创建的大对象（如大型数组、DOM节点）被无意缓存，比如
cache[err.code] = bigData
主动协助回收的实用做法
不需要手动“清空”，但可通过减少隐式引用让GC更高效：
- 避免在catch里做不必要的赋值，尤其不要把局部数据挂到全局或长期存活对象上
- 对大对象，在确认不再需要时主动设为
null（如bigArray = null），帮助标记清除算法更快识别 - 使用
let而非var声明局部变量，确保作用域边界清晰，降低意外泄漏风险 - 若需复用错误信息，建议提取必要字段（如
{ message, code }）而非直接保留整个Error实例
finally不是回收触发点
finally块只是保证执行，它本身不参与变量生命周期管理。即使你在finally里写obj = null，也只是切断当前作用域的引用；如果obj之前已被其他地方持有，GC仍不会回收它。
换句话说：异常发生 → 变量是否回收，由引用图决定；try-catch结构只是语法糖，不改变内存管理规则。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
