Swagger导致Azure App Service内存突增问题排查求助

针对你遇到的Swagger触发内存持续上涨问题，结合.Net 6和Azure App Service环境，给出以下排查和解决方向：

1. 优先排查Swashbuckle版本问题 #

Swashbuckle.AspNetCore（.Net生态最常用的Swagger实现库）在旧版本中存在已知的内存泄漏问题，尤其是重复请求swagger.json时，Schema生成、XML注释解析环节会产生无法被GC正确回收的对象。

• 检查项目中Swashbuckle.AspNetCore的版本，若低于6.4.x，直接升级到最新稳定版（适配.Net 6的v6.x系列最新补丁版或v7.x版本均可）。
• 升级后重复测试swagger.json请求，观察内存是否能在GC后正常回落。

2. 分析内存快照定位泄漏对象 #

利用你已抓取的多份内存快照，重点对比以下对象的增长情况：

• 查找OpenApiSchema、OpenApiDocument、OpenApiPathItem等Swagger核心对象，如果这类对象在多次请求后持续累积且未被GC回收，说明Swagger文档生成过程中存在引用未释放的情况。
• 检查XML注释相关对象（如XDocument、XmlReader实例），若项目启用了XML注释生成Swagger文档，旧版本的解析逻辑可能会残留对象引用。

3. 检查自定义Swagger配置 #

如果项目中自定义了Swagger生成逻辑（比如添加自定义Schema过滤器、文档过滤器），排查以下点：

• 是否存在静态变量缓存OpenApiDocument实例，且每次请求都新增实例而不清理。
• 自定义过滤器中是否持有外部对象的长期引用，导致GC无法回收关联的Swagger对象。

4. 定位凌晨请求的来源 #

凌晨5点的自动内存突增，大概率是自动化请求触发：

• 查看Azure App Service的日志流（Log Stream）或Application Insights日志，确认swagger.json请求的来源IP或用户代理，判断是否是Azure健康巡检、测试环境的定时任务或第三方监控工具触发。
• 若为非必要的自动请求，可在测试环境限制swagger.json端点的访问（比如仅允许内网IP访问，或在非开发环境禁用Swagger）。

5. 临时缓解方案 #

在彻底解决泄漏问题前，可采取以下措施降低影响：

• 在测试环境的Program.cs中，仅在开发环境启用Swagger：

if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

• 调整GC策略，在Program.cs中启用服务器GC并调整回收阈值：

GCServerMode = true;
GC.SetGCHighMemoryPressure(1024 * 1024 * 200); // 200MB触发回收

内容的提问来源于stack exchange，提问作者Kevin