工作站GC适合单用户桌面应用，服务器GC才是Web服务的默认选择
ASP.NET Core 或传统 ASP.NET 应用在 IIS 或 Kestrel 上运行时，默认启用的是
server GC，不是
workstation GC。这个决定由运行时自动判断——只要检测到多核 CPU 和非交互式环境（比如 Windows Server 或 Linux 容器），.NET 运行时就会启用服务器 GC。你手动改错配置，反而可能让 GC 压力更大、暂停更长。
如何确认当前用的是哪种 GC 模式
最直接的方式是查
System.Runtime.GCSettings.IsServerGC的返回值：
Console.WriteLine($"IsServerGC: {System.Runtime.GCSettings.IsServerGC}");也可以通过性能计数器验证（Windows）：
.NET CLR Memory\# of Heaps在服务器 GC 下通常是 CPU 核心数的 2 倍（每个线程池线程对应一个 GC 线程 + 后台 GC 线程），而工作站 GC 固定为 1 个堆。
常见误判点：
本地开发时跑在 Windows 10 上，但用了<servergarbagecollection>true</servergarbagecollection>，结果没生效——因为 .NET 6+ 默认按运行环境自动选型，显式配置只在项目文件中有效且需重启进程 容器里跑 Linux，却依赖 Windows 性能计数器去查，查不到就以为没启服务器 GC
在 csproj 中强制设置 GC 模式（仅限需要干预时）
绝大多数 Web 服务不需要改，但如果你在低配 VM（如 1 vCPU）上跑高吞吐 API，或做 GC 行为对比测试，才考虑显式控制。修改方式是在
.csproj文件的
<propertygroup></propertygroup>里加：
<PropertyGroup> <ServerGarbageCollection>true</ServerGarbageCollection> </PropertyGroup>
注意：
true= 服务器 GC（推荐 Web 服务）；
false= 工作站 GC（适合 WinForms/WPF） 该设置只在编译时写入 runtimeconfig.json，运行时无法动态切换 若同时设置了环境变量
DOTNET_gcServer，它会覆盖 csproj 配置（优先级：环境变量 > csproj > 自动检测） 在 Docker 中，建议用
ENV DOTNET_gcServer=true而不是改 csproj，避免镜像复用时配置僵化
服务器GC的关键行为差异和实际影响
服务器 GC 不是“更快的 GC”，而是“为吞吐和并发设计的 GC”：
堆数量 = CPU 核心数 × 2（.NET 5+ 默认启用concurrent GC，后台线程独立工作） 每次 GC 暂停时间更长（毫秒级），但频率更低，整体吞吐更高 内存占用通常比工作站 GC 高 10%–30%，因为各堆独立管理，碎片和保留内存更多 不支持
GC.Collect()的“紧急回收”语义——调用它只会触发本线程所在堆的 GC，其他堆不受影响 在 .NET 6+ 中，
GCSettings.LatencyMode（如
GCLatencyMode.LowLatency）对服务器 GC 效果有限，仅短暂抑制后台 GC，不能替代正确对象生命周期管理
真正容易被忽略的是：服务器 GC 下的
Gen2回收成本极高，如果频繁分配大对象（>85KB），会直接进 LOH，而 LOH 在服务器 GC 中不压缩（除非 .NET 5+ 开启
gcServer+
gcConcurrent并配合
GCSettings.LargeObjectHeapCompactionMode显式触发），长期运行后容易出现 OutOfMemoryException —— 这不是 GC 类型选错了，是对象尺寸或复用策略有问题。
![EF Core怎么处理二进制数据 EF Core byte[]映射方法](/d/file/efpub/2026/02-21/small0bbb6ce55fa04e1167f773bc4298d7021771666567.jpg "EF Core怎么处理二进制数据 EF Core byte[]映射方法")