HTML函数内存泄漏是软件问题而非硬件故障；因定时器、事件监听器未清理或闭包引用导致对象无法被GC回收，需在组件卸载时手动清除。
HTML 函数运行时内存泄漏不是硬件故障，而是 JavaScript 执行逻辑或 DOM 管理不当导致的软件问题。硬件（如内存条）出问题通常表现为系统级崩溃、随机蓝屏、Page Fault 或 Memory Management 类错误，不会只在特定页面、特定函数调用后稳定复现内存持续增长。
为什么 setTimeout / setInterval 容易引发内存泄漏
它们创建的定时器会持有一个对回调函数及其闭包作用域的强引用。如果回调里又引用了大型 DOM 节点、全局对象或未清理的事件监听器，即使页面跳转或组件卸载，这些对象也无法被 GC 回收。
- 常见错误现象：
performance.memory.usedJSHeapSize持续上升，DevTools 的 Memory 面板中“Heap snapshot”对比显示重复的HTMLDivElement或Closure实例 - 典型场景：单页应用中组件销毁前未
clearTimeout/clearInterval，或把定时器 ID 存在全局变量里却忘了清除 - 参数差异：
setTimeout(fn, 0)和setTimeout(fn, 1000)在泄漏风险上无本质区别，关键在于是否主动清理
addEventListener 绑定后不 removeEventListener 的后果
这是最常被忽略的泄漏源。哪怕只绑一次，只要监听器函数是闭包生成的（比如箭头函数或内联函数），就可能让整个父作用域无法释放。
- 常见错误现象：反复进入/退出同一页面，
Detached DOM tree在 Heap snapshot 中数量递增 - 使用场景：模态框、动态表单、第三方 SDK 初始化（如地图插件）后未解绑
resize或scroll监听器 - 性能影响：泄漏本身不卡顿，但累积到几百 MB 后触发频繁 GC，造成 UI 掉帧甚至标签页无响应
- 实操建议：优先用
{ once: true }选项；若需多次触发，确保用同一个函数引用绑定和解绑（避免用箭头函数直接写在addEventListener参数里）
Vue/React 中看似自动清理，其实要手动干预的地方
框架只负责组件实例本身的销毁，不接管你手写的定时器、IntersectionObserver、ResizeObserver 或 WebSocket 连接。
立即学习“前端免费学习笔记（深入）”；
- Vue 3
onUnmounted里必须显式调用clearInterval(myTimerId)，否则 timer 仍存活 - React
useEffect的 cleanup 函数里，要 return 一个函数来执行解绑，不能只写removeEventListener而不传入原函数引用 - 容易踩的坑：
useCallback包裹的监听器如果依赖了未声明在 deps 数组里的变量，cleanup 时解绑的可能是旧函数，导致新监听器继续泄漏 - 兼容性注意：Safari 对
WeakRef支持较晚（v14.1+），别指望靠它自动兜底
真正难排查的是跨模块隐式引用——比如 A 模块注册了一个全局事件，B 模块监听并存了回调，A 卸载了但 B 忘记取消订阅。这种泄漏不会报错，只会让内存曲线悄悄爬升。别急着换内存条，先打开 Chrome DevTools 的 Memory 标签，录一段操作再拍个 snapshot，比对「Constructor」列里异常多的对象类型更有效。
