javascript执行环境销毁时，引擎自动触发最终垃圾回收，清空全部堆内存；对应页面关闭、worker终止、node.js进程退出等场景，但webgl、websocket等外部资源需手动释放。
JavaScript 执行环境销毁时，内存并不需要“手动释放”，而是由引擎自动完成清理——这个过程不是靠开发者触发，而是依赖垃圾回收器（GC）在环境生命周期结束前的一次最终回收。
执行环境销毁对应哪些场景
常见的执行环境销毁包括：
- 页面完全关闭或刷新，整个全局上下文（如浏览器中的
window）被卸载 - Worker 线程调用
close()或主动终止 - Node.js 进程正常退出（
process.exit()或主模块执行完毕）
销毁前的内存清理机制
当执行环境即将销毁，JS 引擎会执行一次强制的、完整的垃圾回收周期，核心逻辑是：
- 根对象（如全局对象、活动的事件监听器、运行中的 Promise 微任务等）被逐一解除引用
- 所有从根出发不可达的对象，无论是否跨代、是否含循环引用，都会被标记为垃圾
- 标记-清除（Mark-and-Sweep）或标记-整理（Mark-Compact）算法完成最终清扫，释放全部堆内存
- 新生代、老生代、大对象空间等各内存区域一并清空，不遗留存活对象
为什么不需要你写清理代码
与函数执行结束不同，执行环境销毁是顶层生命周期终点。此时：
- 闭包作用域链整体失效，所有内部变量自动失去可达性
- 未清除的定时器（
setInterval）、未解绑的 DOM 事件监听器，在环境卸载后自然失效，不再构成引用 - 引擎不会等待异步操作完成（如 pending 的 fetch、未 resolve 的 Promise），它们的回调不会执行，关联的闭包也被回收
例外情况：资源未被 JS 层管理时需主动处理
JS 自动释放的是 JS 堆内存，但某些外部资源不在此范围内：
-
WebGLRenderingContext、AudioContext等需显式调用close()或destroy() - 通过
URL.createObjectURL()创建的 blob URL，应配合URL.revokeObjectURL() - IndexedDB 连接、WebSocket 实例等，虽 JS 对象会被回收，但底层连接可能延迟关闭，建议主动
close()
这些不属于 JS 垃圾回收职责，而是 Web API 层面的资源管理范畴。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
