firefox devtools 不支持直接触发或实时监控 gc，但可通过内存面板拍快照分析对象留存、启用 chrome 权限后执行 gc() 强制回收、性能面板识别 gc 暂停、console.memory 观察堆使用趋势，并聚焦保留路径定位未回收原因。
Firefox DevTools 本身不提供直接触发或实时监控 JavaScript 垃圾回收（GC）的界面功能，也无法像 Chrome 的 chrome://tracing 或 Node.js 的 --trace-gc 那样输出详细 GC 日志。但它可以通过间接方式辅助你分析内存泄漏和 GC 行为。
使用内存面板观察堆内存变化
Firefox 开发者工具的「内存」面板（Memory）是分析 GC 相关问题的核心入口：
- 打开 DevTools → 点击右上角「⋯」→ 选择「内存」（需 Firefox 90+，且可能默认未启用；若无此选项，可在
about:config中设置devtools.memory.enabled为true） - 点击「拍摄快照」（Take snapshot）获取当前 JS 堆的快照，多次操作后对比对象数量与大小变化
- 执行疑似导致内存泄漏的操作（如反复创建对象、绑定事件但未清理），再拍快照，筛选「已删除但未释放」的对象（例如重复出现的闭包、DOM 引用、全局变量）
- 注意「保留路径」（Retained Path）：它显示某个对象为何未被回收（比如被闭包、事件监听器、WeakMap 外的 Map 持有），这是定位 GC 阻塞点的关键
强制触发垃圾回收（仅限开发者模式）
Firefox 在开发者专属模式下支持通过控制台命令触发 GC，但需手动开启调试权限：
- 在地址栏输入
about:config，搜索并设置devtools.chrome.enabled为true - 打开 DevTools → 切换到「控制台」→ 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS）打开命令菜单 - 输入
garbage collect并执行（或直接在控制台输入gc()—— 注意：该函数仅在启用 chrome 权限且处于浏览器上下文时可用，普通网页中不可用） - 配合内存快照使用：先拍快照 → 执行
gc()→ 再拍快照，观察哪些对象本应被回收却仍存在
结合 performance 面板识别 GC 峰值
虽然不能标记 GC 事件，但 GC 会引发明显的主线程停顿，可从性能曲线中识别：
- 打开「性能」面板 → 点击录制按钮，执行目标操作
- 停止录制后，在火焰图（Flame Chart）中查找长而宽的「Idle」间隙或紧随脚本执行后的空白段——这往往对应 GC 暂停
- 查看「帧率」和「主线程活动」轨道：频繁出现 >50ms 的暂停，且无明显 JS 执行，大概率是 GC 导致
- 导出 JSON 数据后，也可搜索
"name": "GC"字段（部分版本会在 trace 中标记，但非稳定公开 API）
用 console.memory 辅助粗略判断
虽不如 Chrome 精细，Firefox 也支持基本内存读数：
- 在控制台输入
console.memory，返回对象含totalJSHeapSize、usedJSHeapSize、jsHeapSizeLimit - 连续调用并观察
usedJSHeapSize是否持续增长且不回落，提示可能存在无法回收的对象 - 注意：该数据延迟高、精度有限，仅作趋势参考，不可用于精确 GC 分析
不复杂但容易忽略：真正的 GC 调试重点不在“怎么触发”，而在于“为什么没回收”。把精力放在保留路径分析和可复现的内存增长模式上，比等待 GC 日志更有效。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
