1. 生产环境内存一直涨别急着重启服务线上 .NET 服务跑着跑着内存从 800MB 涨到 3GB重启一次能撑两天然后又慢慢爬上去。这种场景我猜你大概率遇到过监控告警响了登录服务器一看进程占用的托管堆只增不减GC 回收了但回收不干净最后只能靠定时重启续命。问题是重启只是把症状压下去根因还在代码里躺着下一次照样涨。.NET 服务内存持续上涨最常见的两类原因是托管内存泄漏和非托管资源没释放。托管泄漏的典型特征是对象被某个 static 字段、事件订阅、缓存字典或者长生命周期容器拿住了GC 认为它还有引用自然不回收。非托管泄漏则多见于HttpClient没复用、SqlConnection没 dispose、Bitmap/Stream没释放这类场景。光看代码很难判断因为泄漏点往往藏在业务逻辑的某个角落调用链可能跨了七八个类。这时候dotnet-dump就派上用场了。它是 .NET 官方提供的 dump 采集与分析工具能在不中断进程的前提下抓取内存快照配合dotnet-dump analyze可以查看对象统计、引用链、GC 根。但说实话dump 分析对大多数业务开发来说门槛不低dumpheap -stat出来几百行类型gcroot出来的引用链又长又绕没有经验很容易看花眼。我自己第一次分析 dump 的时候对着dumpheap -stat的输出愣是没看出哪个类型异常。这篇要讲的就是把dotnet-dump采集和 GPT-5 的代码理解能力结合起来先用dotnet-dump把进程 dump 抓下来再把 dump 和项目源码放在一起让 GPT-5 帮你读对象统计、追引用链、对照业务代码定位泄漏点。适合谁适合那些线上服务内存持续上涨、手头没有专职 dump 分析大佬、但又必须自己硬着头皮上的 .NET 后端开发。下面直接给可复制的采集命令、提问模板和 config.toml 骨架跟着做就行。2. 前置准备dotnet-dump 安装与 TaoToken 接入2.1 安装 dotnet-dumpdotnet-dump是全局工具一条命令装好dotnet tool install --global dotnet-dump装完验证dotnet-dump --version如果之前装过旧版本用dotnet tool update --global dotnet-dump升级。注意采集 dump 的机器上 .NET SDK 或 Runtime 版本要跟目标进程匹配跨大版本采集可能失败。2.2 为什么需要 TaoTokenGPT-5 本身不直接读 dump 文件它读的是你从 dump 里提取出来的文本线索对象统计、引用链、类型名以及你的业务源码。要把这些线索喂给 GPT-5你需要一个稳定的 API 入口。TaoToken 提供统一的模型调用入口支持 GPT-5 系列模型兼容 OpenAI 风格的接口配置简单适合在 codex 或自建脚本里调用。官网地址https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 地址不带 UTMhttps://taotoken.net/api2.3 获取 API Key登录后进入控制台在 API Keys 页面创建一个新 Key控制台入口https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Keys 页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content创建时建议给 Key 起个能识别的名字比如dump-analysis方便后续排查是哪个项目在用。Key 只显示一次复制后存到安全的地方。2.4 config.toml 骨架如果你用 codex CLI 配合 GPT-5 分析需要在项目根目录或用户配置目录放一个config.toml。下面是一个可用的骨架把api_key换成你刚创建的 Key# config.toml - codex 接入 TaoToken 的配置骨架 model gpt-5 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY [profiles.dump-analysis] model gpt-5 model_provider taotoken approval_policy on-request对应的环境变量设置Linux/macOSexport TAOTOKEN_API_KEY你的KeyWindows PowerShell$env:TAOTOKEN_API_KEY你的Key注意不要把 Key 硬编码进config.toml提交到 Git。用环境变量引用env_key字段就是干这个的。3. 可复制配置采集 dump 与提取线索3.1 采集进程 dump先找到目标进程 PIDdotnet-dump ps输出会列出所有 .NET 进程及其 PID。假设目标进程 PID 是12345采集完整 dumpdotnet-dump collect -p 12345 -o /tmp/service_$(date %Y%m%d_%H%M%S).dmp参数说明参数含义建议-p目标进程 PID用dotnet-dump ps确认-o输出文件路径带时间戳方便对比两次 dump--typedump 类型默认Full内存紧张时可用Heap--diag诊断日志采集失败时加排查原因如果进程内存很大比如 8GBFull dump 会比较慢而且文件体积可能跟内存相当。生产环境建议先确认磁盘空间df -h /tmp采集完成后你会得到一个.dmp文件。把它和项目源码放在同一个目录下方便 GPT-5 一边读 dump 线索一边对照代码。3.2 用 dotnet-dump analyze 提取对象统计进入分析模式dotnet-dump analyze /tmp/service_20250101_120000.dmp进去之后先跑对象统计 dumpheap -stat输出会按类型分组列出每种类型的对象数量和总大小。重点关注排在前面的类型尤其是System.Byte[]、System.String、自定义业务类型。比如你看到Statistics: MT Count TotalSize Class Name 00007f8a12345678 15234 312345678 System.Byte[] 00007f8a87654321 8921 45678901 MyApp.Models.OrderCacheItemSystem.Byte[]占了 300MBOrderCacheItem有 8921 个实例这两个都值得追。接着看某个具体类型的实例 dumpheap -mt 00007f8a87654321拿到几个对象地址后追引用链 gcroot 00007f8aabcdef00gcroot会告诉你这个对象为什么没被回收——是被 static 字段拿住了还是被事件订阅挂住了还是在线程栈上。这一步的输出通常很长正是需要 GPT-5 帮忙读的地方。退出分析模式 exit注意dotnet-dump analyze是交互式命令脚本里调用必须用-c参数传命令否则会卡在交互界面。比如dotnet-dump analyze xxx.dmp -c dumpheap -stat -c exit。3.3 把线索整理成 GPT-5 能读的输入GPT-5 不直接读.dmp二进制文件你需要把dumpheap -stat和gcroot的输出保存成文本连同相关源码一起给它。建议这样组织# 提取对象统计 dotnet-dump analyze /tmp/service_20250101_120000.dmp \ -c dumpheap -stat \ -c exit /tmp/dump_stat_1.txt # 提取某个可疑类型的实例 dotnet-dump analyze /tmp/service_20250101_120000.dmp \ -c dumpheap -mt 00007f8a87654321 \ -c exit /tmp/dump_instances_1.txt然后把dump_stat_1.txt、dump_instances_1.txt和你的业务源码目录一起放到 codex 的工作目录里。4. 验证请求让 GPT-5 读 dump 线索定位泄漏4.1 启动 codex 并选择 GPT-5在项目根目录启动终端进入 codexcodex进去后选择模型/model选gpt-5推理档位选high。如果你的config.toml里配了profiles.dump-analysis可以直接codex --profile dump-analysis4.2 提问模板下面是我实测下来比较有效的提问模板直接复制改路径就能用我在排查一个 .NET 服务的内存泄漏问题。当前目录下有 - dump_stat_1.txtdotnet-dump 的 dumpheap -stat 输出 - dump_instances_1.txt某个可疑类型的实例列表 - src/项目源码 请帮我 1. 读 dump_stat_1.txt找出占用内存最多的 5 个类型判断哪些可能是泄漏源 2. 对可疑类型读 dump_instances_1.txt 和源码追引用链定位是哪个 static 字段或长生命周期容器拿住了对象 3. 给出具体的代码位置和修复建议 可用工具dotnet-dump。注意 dotnet-dump analyze 是交互式命令必须用 -c exit 退出否则会卡住。最后那句必须用 -c exit 退出很关键。我踩过的坑就是没告诉它这一点GPT-5 进入dotnet-dump analyze交互模式后就卡在那等输入整个任务停住。明确告知工具用法能省很多来回。4.3 GPT-5 的分析过程回车后 GPT-5 会先列一个计划读统计文件、筛选可疑类型、读源码、追引用链、给结论。然后逐步执行。中间如果需要跑dotnet-dump命令它会请求授权你确认即可。一个典型的分析输出会是这样根据 dump_stat_1.txtSystem.Byte[] 占用 312MBMyApp.Models.OrderCacheItem 有 8921 个实例。 对照 src/Services/OrderCacheService.cs发现 OrderCacheItem 被一个 static Dictionary 缓存 private static readonly Dictionaryint, OrderCacheItem _cache new(); 该字典只增不删没有过期淘汰逻辑。每次查询订单都会写入导致缓存无限增长。 建议改用 IMemoryCache 并设置滑动过期或加容量上限 LRU 淘汰。这就是我们要的结果不是泛泛地说可能有内存泄漏而是定位到具体文件、具体字段、具体修复方向。4.4 对比两次 dump 验证泄漏是否收敛定位到问题、改完代码后怎么确认泄漏真的修好了靠对比两次 dump。第一次 dump 在修复前采集第二次在修复后运行一段时间再采集。然后对比同一类型的实例数量# 修复前 dotnet-dump analyze /tmp/before.dmp -c dumpheap -stat -c exit /tmp/stat_before.txt # 修复后运行 30 分钟后 dotnet-dump analyze /tmp/after.dmp -c dumpheap -stat -c exit /tmp/stat_after.txt对比OrderCacheItem的数量时间点OrderCacheItem 实例数System.Byte[] 总大小修复前8921312MB修复后 30min120448MB修复后 2h118046MB如果修复后实例数稳定在一个区间不再持续上涨说明泄漏收敛了。如果还在涨把两次 dump 的统计文件再喂给 GPT-5让它对比差异继续追。5. 本篇常见错排查5.1 dotnet-dump collect 报 Process not foundPID 写错了或者目标进程不是 .NET 进程。先用dotnet-dump ps确认。如果ps也列不出来检查目标进程的 .NET 版本和dotnet-dump版本是否匹配。5.2 dumpheap -stat 输出里没有业务类型可能 dump 类型选成了Heap而不是Full或者采集时进程刚好在 GC。重新采集一次 Full dump。另外如果业务类型被泛型包装比如ListOrderCacheItem统计里显示的是System.Collections.Generic.List而不是OrderCacheItem需要用dumpheap -type OrderCacheItem单独查。5.3 GPT-5 卡在 dotnet-dump 交互模式这就是前面强调的坑。提问时明确告诉它dotnet-dump analyze要用-c exit退出。如果已经卡住按 CtrlC 中断重新提问并补上这句。5.4 gcroot 输出太长GPT-5 读不完gcroot对复杂对象可能输出几百行。建议先用gcroot -all看概览或者只取前 50 行喂给 GPT-5dotnet-dump analyze /tmp/service.dmp -c gcroot 00007f8aabcdef00 -c exit | head -50 /tmp/gcroot_short.txt5.5 修复后内存还是涨可能有两个泄漏点你只修了一个。重新采集 dump对比修复前后的统计看哪个类型还在涨。也可能是非托管泄漏dumpheap -stat看不出来需要用dotnet-counters看Working Set和GC Heap Size的差异。5.6 API 调用报 401检查TAOTOKEN_API_KEY环境变量是否设置正确以及config.toml里的env_key字段是否跟环境变量名一致。Key 过期或额度用完也会报 401去控制台确认一下。6. 接入文档与后续动作dump 分析这件事工具链本身不复杂难的是从一堆类型和引用链里看出哪个是泄漏源。dotnet-dump负责把现场抓下来GPT-5 负责帮你读线索、对照代码、给修复方向两者配合能把排查时间从加班一整天压到半小时定位。如果你还没配好 API 入口先去创建 KeyAPI Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content想先验证 GPT-5 读 dump 线索的效果可以直接在模型对话里贴一段dumpheap -stat输出试试模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content如果你打算把 dump 分析做成常态化流程比如每次发布后自动采集对比或者集成到 CI 里跑内存回归Coding Plan 更适合长期编码和 Agent 场景Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content最后给一个实用技巧采集 dump 前先记一下进程的GC Heap Size和Working Set分析完再记一次。如果GC Heap Size稳定但Working Set持续涨大概率是非托管泄漏方向要转到HttpClient、SqlConnection、文件句柄这些资源上别在托管堆里死磕。