VS快照需在GC静默后拍摄首张，操作后等待3–5秒再拍第二张；dotnet-dump分析需先threads定位活跃线程，再clrstack -a -t确认上下文，gcroot才有效；Finalizer Queue堆积是泄漏强信号，但需排查终结器阻塞或未抑制问题。
Visual Studio 内置诊断工具快照能快速定位托管堆泄漏，但对非托管泄漏、跨进程场景或生产环境无调试器时基本失效；dotnet-dump 是唯一能离线分析 .NET 6+ 进程内存的官方 CLI 工具，但它不提供“对象增长趋势”对比，必须配合 dumpheap、gcroot 等命令手动推断引用链——两者不是替代关系，而是分工明确：快照用于开发期快速验证，dotnet-dump 用于线上归因。
VS 快照为什么拍不到真实泄漏？
常见错误是刚启动就拍第一张快照，此时大量框架初始化对象（如 AssemblyLoadContext、ConfigurationRoot）还没稳定，导致第二张快照里所有增长都被误判为泄漏。真正有效的对比必须满足三个条件：
- 第一张快照在业务逻辑空闲、GC 已静默运行至少两次后拍摄（可手动调用
GC.Collect(); GC.WaitForPendingFinalizers();后再拍） - 第二张快照必须在复现疑似泄漏操作（如点击 10 次按钮、发起 50 次 HTTP 请求）并等待 3–5 秒后再拍，给 GC 留出回收窗口
- 若项目是 ASP.NET Core +
dotnet watch，快照必然失败并报错Unable to collect memory data: process is not in a debuggable state，必须关掉 watch 或改用dotnet run --no-launch-profile
dotnet-dump 分析时最常卡在 gcroot 找不到引用
执行 dotnet-dump analyze myapp.dmp 后，用 dumpheap -stat 发现 HttpClient 实例暴涨，但 gcroot 却返回 HandleTable 或空结果——这不是工具问题，而是你没切换到正确的线程栈上下文。关键步骤：
- 先用
threads查看所有托管线程，找到疑似泄漏发生时活跃的线程 ID（比如Thread 12） - 用
clrstack -a -t 12看该线程当前调用栈，确认它是否正停在事件回调、Timer 回调或异步延续点上 -
gcroot必须在该线程处于“暂停”状态（即 dump 时刻已冻结）下才有效；若对象被WeakReference包裹，gcroot默认不追踪其Target字段，需额外检查!dumpobj输出中Target是否非 null
Finalizer Queue 堆积 ≠ 内存泄漏，但它是泄漏的强信号
VS 快照里看到 Finalizer Queue 中对象数持续上升，或 dotnet-dump 中 dumpheap -finalizer 显示大量待终结对象，说明 GC 已标记它们为可回收，但终结器线程被阻塞或未调度。典型原因：
- 重写了
Finalize()但没在Dispose()中调用GC.SuppressFinalize(this)，导致对象反复进入终结队列 - 终结器里执行了同步 I/O（如写文件、发 HTTP 请求），在低资源环境下可能永久挂起
- .NET 6+ 中默认启用背景 GC，但若应用设置了
COMPLUS_GCConcurrent=0，终结器线程可能被 Gen 2 GC 长时间抢占
别指望一张快照或一个 dump 就定论泄漏；真正难的是确认“某个类型本不该长期存活”。比如 StringBuilder 在日志组件里缓存了 2000 个实例，得顺着引用链查清是哪个静态 ConcurrentQueue<string> 在不断 Add 而不消费——这一步没有自动工具能代劳，只能靠人盯住 Inclusive Size 和引用路径里的 static 字段、事件订阅、Timer 回调这三类高危节点。
