存在JavaScript内存泄漏时，应先用Chrome任务管理器初筛，再通过Performance面板观察JS Heap曲线是否不回落，接着用Memory面板执行“GC+三快照+对比”定位增长对象，最后用getEventListeners和querySelectorAll命令直查监听器与DOM节点泄漏。
当你在测试页面时发现操作几次后页面变卡、内存占用持续上涨且不回落，说明可能存在JavaScript内存泄漏，必须快速定位到具体代码位置才能推进修复。
用浏览器任务管理器做30秒初筛
按 Shift+Esc 直接唤出 Chrome 任务管理器，找到对应网页进程，观察“内存”列数值：静置10秒后若仍缓慢爬升（如每30秒涨超50MB），或重复执行同一操作（如打开/关闭弹窗）10次后内存阶梯式上涨，就基本可判定存在泄漏。
这一步跳过DevTools直接看系统级指标，避免被快照延迟或GC干扰误判。
Performance面板抓取动态泄漏证据
这是定位“只增不减”型泄漏最直观的方法，能锁定泄漏发生的具体时间点和行为。
立即学习“Java免费学习笔记（深入）”；
第一步：打开开发者工具 → 切换到 Performance 面板 → 勾选 Memory 和 Screenshots → 点击录制按钮 ●
第二步：执行一次疑似泄漏的操作（例如点击“加载更多”按钮5次）→ 操作结束立即点停止 ■
第三步：在火焰图下方的内存曲线中，找蓝色JS Heap线——如果操作结束后线条未回落甚至继续上扬，说明对象未被回收；把鼠标悬停在线条峰值处，下方Summary区域会显示该时刻新增的DOM节点数、监听器数等关键指标。
注意：若Memory未勾选，整条曲线将不显示，无法判断JS堆变化。
Memory面板拍快照比对增长对象
快照对比是定位泄漏源头的核心手段，但必须严格遵循“先GC再拍照”流程，否则数据全是噪音。
在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。
方法一：基础三快照法
① 打开Memory面板 → 点击垃圾桶图标 Collect garbage → 点击 Take heap snapshot，命名为 “Snapshot 1”
② 执行一次完整业务操作（如进入列表页→点击某项→返回）→ 再次点击垃圾桶 → 拍摄 “Snapshot 2”
③ 重复步骤②一次 → 拍摄 “Snapshot 3”
方法二：精准对比模式
在 Snapshot 3 的左上角下拉菜单中选择 Comparison → 顶部切换为 Objects allocated between snapshots 2 and 3 → 展开后重点查看 (closure)、EventListener、HTMLDivElement、Detached DOM tree 这几类构造函数的新增数量；若某类对象持续增长（如 closure 多出200+个），右键它 → 选择 Reveal in Summary view → 查看右侧 Retainers 树，就能看到是哪个模块、哪行代码强引用了它。
【关键前提】每次拍照前必须手动点垃圾桶触发GC，否则快照里塞满本该回收的对象，对比完全失真。
控制台命令直查高危泄漏点
80%的内存泄漏来自事件监听器残留和脱离DOM节点，这两条命令能绕过快照分析，3秒内给出线索。
输入 getEventListeners(document) 回车，查看全局监听器总数；反复执行组件切换操作后再次运行，若监听器列表明显变长（尤其出现重复绑定的 scroll、resize），说明未调用 removeEventListener。
输入 console.dir(document.querySelectorAll('*').length) 获取当前DOM节点总数；再执行可能造成节点堆积的操作（如无限加载），若节点数暴涨且不回落，配合Elements面板搜索 detached 可快速定位残留节点。
