JavaScript内存溢出本质是内存持续累积且GC无法清理，解决需打断阻塞（如拆分任务）和切断意外引用（如清除监听器、定时器），并用DevTools监控泄漏点。
JavaScript 长时间运行后出现内存溢出，本质不是“用了太久”，而是“该释放的没释放，该交还的没交还”。关键不在运行时长，而在内存是否持续累积且无法被垃圾回收器（GC）清理。解决思路围绕两个核心：**打断阻塞、切断意外引用**。
避免同步无限循环霸占事件循环
像 while(true) 或深度递归这类同步“永动”逻辑，会彻底堵死事件循环——GC 没机会运行，临时对象、闭包上下文、甚至 console 缓冲区都会越积越多，最终触发 JavaScript heap out of memory。
- 用
setInterval或setTimeout把大任务拆成小片段，每次执行后主动让出控制权 - 浏览器环境优先选
requestAnimationFrame，它天然与渲染帧对齐，更稳定且利于 GC - Node.js 中可结合
process.nextTick或Promise.resolve().then()实现微任务调度，避免阻塞
清理所有隐式持久化引用
GC 只回收“不可达”对象。只要某个对象还能从根（如 window、global、当前调用栈）被访问到，它就永远不会被清除。常见“隐形钉子”包括：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 动态添加的事件监听器未移除：节点已销毁，但 handler 仍持有着对 DOM 或闭包变量的引用
- 定时器未清除：尤其是
setInterval，若回调中引用了外部大对象，该对象将长期驻留 - 闭包意外捕获大对象：内层函数只用其中一两个字段，却因作用域链保留了整个外层上下文
- 全局变量或
window属性被无意赋值：未声明变量（如data = [...]）自动挂载到window，永不释放
监控与定位真实泄漏点
不能靠猜。必须用工具确认哪些对象在增长、谁在引用它们：
立即学习“Java免费学习笔记（深入）”；
- Chrome DevTools → Memory 面板 → 拍摄堆快照（Heap Snapshot），对比操作前后差异，按“Retained Size”排序，看哪些构造函数实例数量或体积异常增长
- 使用 “Allocation instrumentation on timeline” 录制内存分配过程，直接看到哪段代码在高频创建对象
- Node.js 启动时加
--inspect，然后用 Chrome 访问chrome://inspect进行同等分析 - 代码中定期调用
process.memoryUsage()打印heapUsed，观察趋势是否单边上升
采用内存友好的数据与结构模式
有些做法看似方便，实则埋下隐患：
- 大数组/对象不一次性加载：用流（Stream）、分页、迭代器（
for...of+yield）逐块处理 - 缓存用
WeakMap/WeakSet：键是对象引用，不阻止 GC；适合做元数据映射或私有状态存储 - 避免深克隆大数据：优先用不可变更新（如
immer）或结构共享 - 手动解除强引用：不再需要时，显式设为
null（仅当确认无其他引用时有效）
