JavaScript垃圾回收无法在Performance Timeline中直接看到，但可通过JS Heap曲线突变（陡降+回升、平台期骤降、高频小幅波动）间接识别，并结合performance.memory和performance.mark()辅助验证与打标。
JavaScript 的垃圾回收（GC）无法直接通过 Performance Timeline 的 UI 界面“看到”具体某次 GC 的触发时间或类型，但可以通过 内存使用曲线的突变特征 间接识别 GC 行为，并结合 Performance API 捕获关键指标。Chrome DevTools 的 Performance 面板是主要观测入口，需配合正确录制和解读方式。
录制时必须启用内存堆快照采样
默认录制不包含内存数据。需手动勾选：
- 打开 DevTools → Performance 面板
- 点击右上角 ⚙️ Settings（齿轮图标）
- 在 Recording 区域勾选 Memory（含 JS heap、nodes、documents、listeners 等）
- 点击录制按钮，执行目标操作后停止
未启用此选项，Timeline 中将只有 CPU、网络、渲染等轨迹，看不到任何内存曲线，更无法推断 GC。
从 JS Heap 曲线识别 GC 发生时刻
GC 不会显示为独立事件标记，但会在 JS Heap (MB) 轨迹中留下典型形态：
立即学习“Java免费学习笔记（深入）”；
- 陡降 + 回升：一次完整 GC 周期常表现为内存占用突然下降（回收不可达对象），随后因新对象分配小幅回升
- 平台期后骤降：若内存长期平稳后出现明显下跌（如从 80 MB 直降到 45 MB），大概率是全量 GC（Mark-Sweep 或 Minor GC 后的整理）
- 高频小幅波动：频繁的小幅上下跳动（如 ±2–5 MB），多对应 V8 的 Scavenger（新生代 GC），说明大量短生命周期对象被快速回收
注意：仅靠曲线不能区分 GC 类型（Scavenge / Mark-Sweep / Incremental / Compaction），需结合 Event Log 或 Bottom-up / Call Tree 查看是否出现 GC Event 标签（新版 Chrome 已弱化该标签，部分版本仍可见）。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
用 performance.memory 辅助验证（仅限页面内脚本）
虽然 Performance Timeline 不暴露 GC 时间戳，但运行时可通过 performance.memory 获取近似内存状态（仅 Chromium 系浏览器支持）：
-
performance.memory.totalJSHeapSize：JS 堆总申请字节数 -
performance.memory.usedJSHeapSize：当前已用字节数 -
performance.memory.jsHeapSizeLimit：堆大小上限
可在关键节点（如批量创建对象前后）打印这些值，观察 usedJSHeapSize 是否在预期 GC 后显著回落。例如：
console.log('Before GC:', performance.memory.usedJSHeapSize / 1024 / 1024 + ' MB');
// 触发潜在 GC（如主动释放引用、等待空闲）
setTimeout(() => {
console.log('After GC:', performance.memory.usedJSHeapSize / 1024 / 1024 + ' MB');
}, 100);
⚠️ 注意：performance.memory 是只读快照，不实时更新；且受 V8 内存管理策略影响，数值变化不一定严格对应单次 GC。
高级技巧：结合 User Timing 打标 GC 关键点
若需精确对齐 GC 与业务逻辑，可用 performance.mark() 主动打点：
- 在疑似触发 GC 的操作前打标：
performance.mark('gc-before-heavy-op') - 操作完成后立即打标：
performance.mark('gc-after-heavy-op') - 录制后在 Performance 面板的 Timings 轨道查看标记位置，对照 JS Heap 曲线下降段判断 GC 是否发生于该区间
此方法不检测 GC 本身，但能将内存行为与代码路径强关联，适合定位特定函数是否引发高频回收。
