需联动performance与memory面板分析高吞吐生成器内存指纹：先启用chrome://flags/#enable-devtools-performance-memory-infra并重启，勾选screenshots、memory、fps meter；再用performance定位迭代窗口，配合堆快照溯源对象。
要定量分析高吞吐生成器（如 function* 或 AsyncGenerator）在迭代过程中的内存指纹，不能只看单一时序曲线，必须将 Performance 面板的连续监控能力与 Memory 面板的精确堆快照深度联动——关键在于“时间锚定”和“对象溯源”。
一、先确保 Performance 面板能捕获有效内存时序
Chrome 默认不采集内存数据。录制前必须完成两步硬性配置：
- 打开
chrome://flags/#enable-devtools-performance-memory-infra，设为 Enabled，并彻底关闭所有 Chrome 进程后重启（仅刷新标签页无效） - 在 Performance 面板右上角 ⚙️ → Recording 中，勾选：screenshots（必需）、memory（此时应已可点击）、fps meter
验证：开始录制后，时间轴顶部应出现带锯齿的 JS Heap 折线，且纵坐标单位为 MB；若无折线或显示 “No memory data”，说明 flag 未生效或未重启。
二、用 Performance 定位“可疑迭代窗口”
高吞吐生成器往往在短时间内密集调用 next()，导致内存阶梯式上升。操作如下：
- 在页面中注入可控测试逻辑，例如：
for (let i = 0; i ，并在循环前后插入console.timeStamp('gen-start')和console.timeStamp('gen-end') - Performance 录制中执行该逻辑，停止后在 Main 轨道查找对应
console.timeStamp标记，框选其覆盖的时间范围（即“迭代窗口”） - 观察该窗口内 JS Heap 是否呈现持续爬升且无回落（非瞬时尖峰），同时检查 Memory 轨道是否同步显示 DOM 节点数、监听器数等指标同步增长
三、在精确时间点触发堆快照做横向比对
Performance 只能告诉你“内存涨了”，但无法告诉你“涨的是什么”。需用 Memory 面板补全对象级证据：
- 回到同一页面，在迭代开始前，切换到 Memory 面板 → 点击 Take Heap Snapshot，保存为 Snapshot 1
- 执行同一批次生成器迭代（建议用相同循环次数，避免干扰）
- 立即再拍一张快照，命名为 Snapshot 2；如有必要，再执行一次迭代后拍 Snapshot 3
- 在 Snapshot 2 的筛选框输入 Comparison，选择与 Snapshot 1 对比，重点关注：
– Delta 列为正且数值大的构造函数（如 Array、Object、Closure）
– 搜索 generator 或 AsyncGenerator，查看其实例数量与 Retained Size 是否异常放大
– 筛选 Detached，确认是否有因闭包持有未释放的 DOM 或事件监听器
四、交叉验证：从快照反推 Performance 时间戳
若 Snapshot 2 显示某类 Closure 的 Retained Size 达 12MB，可在 Performance 的 Main 轨道中搜索该 Closure 名称（如 createChunkProcessor），定位其首次分配和后续重复调用帧，确认是否集中在你标记的“迭代窗口”内。这一步把抽象内存增长锚定到具体函数调用链，形成闭环证据。
不复杂但容易忽略：生成器本身不直接分配大对象，问题常出在 yield 值的缓存策略、闭包对外部作用域变量的意外捕获，或 next() 返回值未被及时释放。定量指纹，就是用 Performance 锁定时间窗 + 用快照锁定对象类型 + 用对比 Delta 锁定增量来源。
