Performance面板排查内存泄漏的核心是观察JS Heap曲线是否“只升不降”，结合Nodes/Listeners走势及手动gc()验证；开启Memory录制后，通过阶梯式上升、末端显著偏高、辅助曲线同步上涨识别泄漏，并借助Call Tree定位闭包或事件监听器等源头。
直接用 Performance 面板排查内存泄漏，核心是看 JS Heap 曲线是否“只升不降”，再结合 Nodes/Listeners 走势和手动 GC 验证，而不是等它爆满才行动。
开启内存录制并模拟真实操作
打开 DevTools → 切到 Performance 面板 → 勾选 Memory 复选框（不勾就看不到内存数据）→ 点击左上角圆形录制按钮 → 在页面执行你怀疑的操作（比如反复打开关闭弹窗、切换路由、滚动加载列表）→ 点击停止。
录制完成后，时间轴下方会显示 JS Heap、Nodes、Listeners、Documents 四条曲线。JS Heap 是主判断依据，其他是辅助线索。
识别泄漏的三类典型曲线特征
正常情况：JS Heap 呈锯齿状波动——每次上升后，因垃圾回收（GC）出现明显回落，最终回到接近起点的位置。
泄漏迹象：
- 阶梯式持续上升：每次操作后内存不回落，或回落幅度越来越小
- 末端明显高于起点（例如高 20% 以上），且多次操作后未收敛
- Nodes 或 Listeners 曲线同步阶梯上涨，大概率是 DOM 节点未释放或事件监听器堆积
定位可疑时段与调用源头
把鼠标悬停在 JS Heap 明显上升的一段上，下方详情区域会显示该时段的活动摘要。点击该片段，再切到底部的 Bottom-Up 或 Call Tree 标签页：
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
- 找 Self Time 或 Aggregated Time 异常高的函数
- 展开调用链，注意频繁分配大对象的位置（如
new Array(1e6)、document.createElement） - 重点标记为
(closure)或含EventListener的条目，它们常是泄漏起点
用 gc() 验证泄漏是否真实存在
录制结束后别急着下结论。先切到 Console 面板，输入 gc() 并回车（需提前在 DevTools 设置 → Experiments 中启用 “Disable JavaScript sampling” 和 “Enable advanced heap snapshot features”）。
再返回 Performance 面板观察 JS Heap 变化：
- 如果内存纹丝不动，说明有强引用阻止释放，泄漏基本坐实
- 如果明显回落，可能是暂时性占用，需结合业务逻辑判断是否合理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
