服务器gc是web服务默认选择，.net运行时自动启用；工作站gc仅适用于单用户桌面应用。可通过gcsettings.isservergc或性能计数器验证，配置优先级为环境变量＞csproj＞自动检测。
工作站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 个堆。
常见误判点：
云枫工作室企业网站源代码(.net)Version 4.0 是云枫工作室基于.net环境独立开发的一套适用于企业使用的企业网站系统。.net+access.网站使用了模板动态生成静态页面技术，前台页面是生成纯静态的。网站包括了信息管理，产品管理，新闻管理和在线留言。可以在后台设置网站名称，标题，关键字和网站描述。配置说明：服务器空间需要支持.net2.0,还要有可写的权限（这个是必要的，因为网站前
- 本地开发时跑在 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 类型选错了，是对象尺寸或复用策略有问题。
