支配者树是堆快照中基于GC Roots可达路径推导出的逻辑结构：若对象A是B的支配者，则所有从GC Roots到B的路径必经A，释放A将导致B及其支配子树全部可被回收；它用于定位内存泄漏的“总开关”，如Chrome DevTools Dominators视图中Retained Size占比高的节点。
什么是支配者树（Dominator Tree）？
支配者树不是一棵真实存在的树，而是堆快照分析中根据对象引用关系推导出的逻辑结构：如果对象 A 是对象 B 的支配者，意味着从 GC Roots 到 B 的所有路径都必须经过 A；换句话说，A 不被回收，B 就不可能被回收。
它直接反映“谁卡住了内存释放”。在 Chrome DevTools 或 MAT 中，Dominators 视图默认按 Retained Size 降序排列，排在最上面的几个节点，往往就是内存泄漏的“总开关”。
Chrome DevTools 中如何快速查看并验证支配者
打开 Memory 面板 → 拍摄堆快照 → 切换到 Dominators 标签页：
- 重点关注
Retained Size占比超过 10% 的前几行，尤其是构造函数为(closure)、Object、Array或自定义类名（如UserCache、DataTable）的条目 - 双击某一行，右侧会显示该对象的
Retaining tree（保留树），展开后能看到它持有哪些子对象、这些子对象又持有哪些引用 - 留意
retained size明显高于shallow size的对象——说明它本身不大，但拖着一堆“亲戚”不肯走 - 右键点击对象 →
Reveal in Summary view可跳转回摘要视图，再点Constructor查看同类所有实例数量，确认是否批量泄漏
常见支配者陷阱与误判点
支配者树容易把“无辜的中间人”当成元凶，尤其在以下场景：
-
window或globalThis常是顶层支配者，但它只是宿主环境入口，真正问题往往藏在它的某个属性里（比如未清理的window.cacheMap） - 闭包（
(closure)）频繁上榜，但需点开看它捕获了哪个外层变量——若捕获的是一个已卸载组件的this或大数组，才是真凶；若只是捕获了几个字符串或数字，可忽略 - 第三方库对象（如
lodash.throttle返回的函数、React.Component实例）可能因生命周期管理不当成为支配者，但根源常在调用方没调用cleanup或unmount - DOM 节点若显示为
Detached DOM tree的支配者，说明它们已被移除但仍有 JS 引用（如事件监听器、数据绑定、缓存 map），此时应检查对应 JS 对象的Retaining tree中是否有EventListener或data属性
Node.js 环境下支配者分析的特殊注意事项
Node.js 使用 --inspect 连接 Chrome DevTools 时，支配者树逻辑一致，但有几点必须注意：
- 必须启用
--expose-gc并在拍快照前手动调用global.gc()，否则大量本可回收的对象仍处于“待回收”状态，导致支配者树失真 - Node.js 的
require缓存（Module._cache）和process对象天然是强支配者，不要一看到它们就 panic，先展开看它具体持有了哪些模块或监听器 - 使用
cluster或worker_threads时，每个线程/进程需单独分析，主进程的支配者树不反映子线程内存状态 - 若用
jmap导出 HPROF 文件给 MAT 分析，MAT 的支配者树更稳定（因绕过 V8 引擎限制），但丢失 JS 执行上下文信息，无法直接看到闭包捕获的变量名
支配者树真正的价值不在“谁最大”，而在“谁断开了，整片内存才能释放”——盯住那个 Retained Size 最高、且明显不该长期存活的对象，顺着它的 Retaining tree 往下挖三层，90% 的泄漏根源就藏在那里。
