JavaScript构造函数抛出异常不会导致JS堆内存泄漏，但若中途创建了需手动清理的外部资源（如WebSocket、定时器、事件监听器等）且未在throw前显式释放，就会造成隐性资源泄漏；必须按创建逆序主动清理，推荐用工厂函数+try/finally封装保障清理必达。
JavaScript 中构造函数本身不能直接抛出异常来触发类似 C++ 那样的资源泄漏风险（因为 JS 没有手动内存分配如 new char[]），但若在构造过程中创建了需手动清理的**外部资源**（如定时器、事件监听器、WebSocket、Canvas 上下文、第三方库实例等），而构造中途失败又未清理，就可能造成隐性泄漏。关键不是“JS 会不会泄漏”，而是“你创建的那些非 JS 堆对象有没有被及时释放”。
构造中提前返回或抛出前，必须显式清理已创建资源
JS 构造函数一旦执行到 throw，后续代码不再运行，也不会自动调用任何“析构逻辑”。所以所有清理动作必须由开发者在抛出前主动完成。
- 按创建顺序的逆序逐个清理：先建的后清，避免依赖关系出错
- 每个资源清理操作应具备幂等性（重复调用不报错）
- 把清理逻辑封装成独立方法，便于复用和测试
用工厂函数替代构造函数，提升控制力
直接调用 new MyClass() 容易让清理逻辑散落在构造函数内部。改用工厂函数可明确分离“创建”与“清理”流程：
- 工厂内创建资源 → 尝试初始化 → 成功则返回实例；失败则立即清理并抛出
- 避免在构造函数里混杂业务校验和副作用操作
- 示例中可统一处理错误路径，保证资源不残留
结合 finally 或 try/catch 确保清理必达
即使构造逻辑较复杂，也可用 try...catch...finally 包裹关键步骤，把清理逻辑放在 finally 块中——它无论是否抛出异常都会执行：
立即学习“Java免费学习笔记（深入）”；
-
finally不适合做“成功后的收尾”，只适合做“无论如何都要做的兜底清理” - 注意：
finally中不要throw新异常，否则会覆盖原错误 - 适用于临时资源（如一次性 fetch controller、临时 canvas context）
优先使用可自动管理的资源抽象
减少手动清理负担的根本办法，是选用自带生命周期管理能力的封装：
- 用
AbortController控制 fetch / setTimeout / event listener，统一 abort 即可中断全部 - 对 DOM 监听器，用
{ signal }选项绑定到 AbortSignal - 自定义类内部用
WeakRef或FinalizationRegistry（谨慎使用）做弱引用兜底 - 第三方库尽量选支持 .destroy() / .close() / .teardown() 方法的版本
