Firefox DevTools 无独立Memory面板和堆快照功能，但可通过Performance面板勾选Memory、录制操作观察JS Heap/DOM Nodes/JS Listeners趋势，结合gc()触发回收、console.memory监控及代码审计定位泄漏。
Firefox DevTools 没有像 Chrome 那样独立的「Memory 面板」，也不支持堆快照（Heap Snapshot）或 Detached DOM 分析这类深度内存诊断功能。但它提供了实用的替代路径，能有效辅助识别内存泄漏趋势和可疑对象。
Firefox 的内存排查靠 Performance + 内存指标组合
打开 DevTools（Ctrl+Shift+I / Cmd+Opt+I），切换到 Performance 面板，勾选顶部的 Memory 复选框（必须手动开启，否则不采集）。点击录制按钮（●），执行疑似泄漏的操作（如反复进入/退出页面、开关弹窗 5 次），停止录制后查看时间线图表。
重点关注以下三条曲线：
- JS Heap：JavaScript 堆内存使用量，看下限是否逐轮抬升（不是峰值，是操作结束后稳定下来的最低值）
- DOM Nodes：节点总数，若持续增长且不回落，说明 DOM 未被真正释放
- JS Listeners：事件监听器数量，增长后不归零，大概率存在 addEventListener 未 remove
手动触发 GC 并观察回收效果
Firefox 不提供一键“Collect garbage”按钮，但可通过以下方式间接触发：
- 在 Console 中输入
gc()（仅在启用javascript.options.gc且运行于本地文件或开发服务器时有效；部分版本需启动参数--jsconsole或通过 about:config 开启调试权限） - 更可靠的做法：反复刷新页面 + 执行操作，对比多轮 JS Heap 下限变化——若每轮操作后下限都比上一轮高 2–5MB 且不收敛，即为强泄漏信号
用 Debugger 配合 console.memory 辅助定位
Firefox 支持 performance.memory（Chrome 同源 API），可在控制台运行：
setInterval(() => {
if (performance.memory) {
console.log('Heap:', Math.round(performance.memory.usedJSHeapSize / 1024 / 1024 * 100) / 100, 'MB');
}
}, 2000);注意：该 API 在 Firefox 中默认可用，无需额外参数；数值抖动属正常现象，关键是看重复操作后能否回落到接近初始值。
查泄漏源头：靠代码审计 + 排查模式
当 Performance 确认存在增长趋势后，回到代码，重点检查：
- 组件卸载（如 React useEffect cleanup、Vue beforeUnmount）中是否遗漏
removeEventListener、clearInterval、abortController.abort() - 是否将 DOM 元素、响应数据、大型数组赋值给了全局变量或模块级缓存（如
window.cache = data、const store = new Map()未清理） - 第三方库调用后是否调用了
.destroy()、.dispose()等清理方法（尤其图表、富文本、地图组件）
小技巧：禁用 DevTools 后再测一次
Firefox 中 console.log(大对象) 同样会因日志系统强引用导致内存阶梯式上涨。若发现内存只在 DevTools 打开时持续增长，关闭后操作完全正常，则很可能是调试日志引发的间接泄漏——删掉或节制 console.log 参数即可缓解。
Firefox 当前不支持 Retainers 引用链追踪，也无法直接看到 (detached) 节点。所以它更适合做泄漏定性与范围缩小，精确定位仍需结合 Chrome 的 Memory 面板交叉验证，或靠逻辑推理+代码审查收口。
