Chrome DevTools不提供“垃圾碎片率”指标，但可通过GC后剩余堆占用与峰值分配量比值、堆快照对比中不可达对象模式、V8内存统计（需启用参数）三类可观测指标，定量评估深度拷贝对内存健康度的影响。

Chrome DevTools 内存分析器不直接提供“垃圾碎片率”这一指标，V8 引擎也未对外暴露碎片率的量化数值。所谓“垃圾碎片率”并非标准内存术语，它常被误用于描述堆中因频繁分配/释放导致的不可用小块空闲内存占比，但该值无法通过 DevTools 界面或 API 直接读取或计算。

不过，你可以通过以下可测量、可复现、有明确意义的替代指标，定量评估深度拷贝大型嵌套字面量（如 JSON.parse(JSON.stringify(obj)) 或结构化克隆）对内存健康度的实际影响：

---

? 1. 关注「GC 后剩余堆占用」与「峰值分配量」比值

这能间接反映碎片压力：高碎片常导致 GC 后仍残留大量不可合并的小空闲块，使堆无法有效收缩。

操作步骤：

• 打开隐身窗口（禁用所有扩展）
• 在 Memory 面板 → 选择 "Allocation instrumentation on timeline"（非堆快照）
• 点击录制按钮 → 执行一次深度拷贝（例如拷贝一个 5MB 的嵌套对象）→ 停止录制
• 观察时间轴：
  • 记录 峰值 JS Heap（蓝色曲线顶点），记为 PeakAlloc
  • 手动点击左上角垃圾桶图标触发 GC → 等待几秒 → 查看 GC 后稳定值，记为 PostGCMem
• 计算比值：PostGCMem / PeakAlloc

✅ 健康参考：

• 若比值 < 0.25：堆回收高效，碎片影响小
• 若比值 > 0.6 且多次重复后持续升高：说明拷贝行为引发大量短生命周期对象 + GC 未能充分整理，碎片风险上升

? 提示：使用 performance.memory（需在安全上下文）可编程获取：

// 执行拷贝前后各调一次
console.log(performance.memory.usedJSHeapSize, performance.memory.totalJSHeapSize);

---

? 2. 用堆快照对比识别「不可达但未回收」对象模式

深度拷贝若配合闭包、缓存或意外引用，可能产生本应被回收却滞留的中间对象（如临时数组、解析器状态）。

操作步骤：

• 拍摄 Baseline 快照（GC 后）
• 执行 1 次深度拷贝（不保留引用，确保无变量捕获结果）
• 立即手动 GC → 拍第二张快照
• 切换到 Comparison 视图，筛选：
  • 构造函数含 Array、Object、String
  • # New > 0 且 Retained Size 总和 > 1MB
• 展开可疑条目 → 查看 Retaining Tree：
  • 若顶层是 <string>、<array> 或 system / context，属正常临时对象
  • 若顶层是 window.xxx、setInterval、Map 或某个长期存活 class 实例 → 存在隐式持有，非碎片而是真实泄漏

---

⚙️ 3. 观察 V8 内部统计（需启用 --enable-precise-memory-info）

仅限本地调试，需启动 Chrome 时加参数：

chrome --enable-precise-memory-info --user-data-dir=/tmp/chrome-mem-test

之后在 DevTools Console 中执行：

// 需在页面上下文中运行（非控制台沙箱）
chrome.memory.getInfo().then(info => {
  console.table({
    'Heap Size': info.jsHeapSizeLimit,
    'Used Heap': info.jsHeapSizeUsed,
    'Fragmentation': ((info.jsHeapSizeLimit - info.jsHeapSizeUsed) / info.jsHeapSizeLimit * 100).toFixed(1) + '%'
  });
});

⚠️ 注意：此 Fragmentation 是粗略估算（总空闲 / 总上限），不是真实碎片率，但可用于横向对比同一场景下不同拷贝方式（如 structuredClone vs lodash.cloneDeep）的差异。

---

✅ 实用建议：降低拷贝副作用

• 优先用 structuredClone()（现代浏览器支持），它比 JSON.parse(JSON.stringify()) 更高效、更少中间对象
• 避免在循环或高频事件中深度拷贝；改用 immutable 更新策略（如 Immer）或只拷贝必要字段
• 对超大对象，考虑流式序列化或分片处理，避免单次大分配

---

DevTools 不提供碎片率仪表盘，但以上三类可观测指标已足够判断深度拷贝是否正在恶化内存健康度。重点不是数字本身，而是趋势变化：相同操作下，PostGC / Peak 比值是否逐次升高？Comparison 中新生对象是否稳定累积？这才是真正需要干预的信号。