Dynamic PGO 是 .NET 7+ 运行时自动启用的自适应优化机制，通过 JIT 在运行中采集热点路径等动态反馈并重编译高效代码，区别于需离线采集 profile 的传统 PGO；它仅在 Release 构建、分层编译和 TieredPGO 启用时生效。
目前 .NET 7+ 中的 Dynamic PGO（Profile-Guided Optimization）不是开发者手动“开启”的功能，而是运行时自动启用的优化机制——它依赖于 JIT 编译器在应用运行过程中收集热点路径、虚方法调用分布、分支走向等动态反馈，并据此重新编译更高效的代码。你无法像配置开关一样直接调用 EnableDynamicPGO，但可以显著影响它的效果。
Dynamic PGO 是什么，和传统 PGO 有什么区别？
传统 PGO 需要先采集典型负载下的运行 profile（如使用 dotnet-pgo 工具），再离线训练、生成 .pgo 文件，最后在发布时注入到程序集中——整个流程与部署强耦合，难以适应多变的生产环境。
Dynamic PGO 则完全不同：它在进程运行时持续采样（默认启用），由 NGEN/JIT 后端自动触发重编译（Tier-1 → Tier-2 升级），无需人工干预或额外构建步骤。它的核心优势是“自适应”——同一份二进制，在不同硬件、不同负载下会生成不同的优化结果。
关键前提：Dynamic PGO 仅在 Release 构建 + COMPLUS_TieredPGO=1（.NET 6 默认开启，.NET 7+ 默认强制启用）且未禁用分层编译（COMPLUS_TieredCompilation=1）时生效。
如何确认 Dynamic PGO 正在工作？
最直接的方式是观察 JIT 日志和 Tier 升级行为：
从 CSV 数据集生成图数据库加载器和三元组映射。将表格 CSV 数据转换为图数据库可直接使用的节点、边和三元组。
- 启动时设置环境变量：
COMPLUS_JitDisasm=*+COMPLUS_JitLogCsv=1，然后检查输出中是否出现Tier0→Tier1→Tier2的多次编译记录 - 使用
dotnet-counters monitor -p <pid> --counters Microsoft.NETCore.DotNetRuntime</pid>，观察Active Tier-1 Jitted Methods和Active Tier-2 Jitted Methods是否随时间增长 - 对关键方法加
[MethodImpl(MethodImplOptions.AggressiveOptimization)]并配合COMPLUS_ReadyToRun=0（禁用 R2R），可强制其进入 Tier-2 流程，便于验证
注意：Dynamic PGO 不会在首次冷启动就优化——它需要一定时间（通常几百毫秒到几秒）完成热身采样。因此压测前务必预留 warmup 阶段（如循环调用目标方法 1000 次以上）。
哪些代码模式能显著受益于 Dynamic PGO？
Dynamic PGO 对以下场景优化效果最明显：
- 频繁调用的虚方法/接口方法：JIT 能根据实际调用目标（如 95% 是
ConcreteA，5% 是ConcreteB）做去虚拟化（devirtualization）甚至内联 - 带条件分支的热点方法：如
if (flag) { ... } else { ... }，若某分支长期不执行，JIT 可将其标记为“冷路径”，减少指令缓存污染并优化热路径布局 - 泛型实例化方法：特别是
IEnumerable<t></t>链式调用（如Where().Select().ToList()），PGO 帮助识别真实类型分布，提升内联决策质量
反例：纯计算密集型但无分支/虚调用的函数（如简单向量加法），PGO 带来的收益极小；而大量反射、dynamic 或 Expression.Compile() 生成的代码，因脱离 JIT 视野，基本不受 PGO 影响。
常见干扰项和必须关闭的选项
以下配置会直接禁用或削弱 Dynamic PGO 效果：
-
COMPLUS_TieredCompilation=0：彻底关闭分层编译，PGO 失效 -
COMPLUS_TieredPGO=0：.NET 6 中可手动关闭，.NET 7+ 忽略该设置但设为 0 仍可能触发兼容性降级 - 发布时启用
ReadyToRun（即dotnet publish -p:PublishReadyToRun=true）：R2R 映像会抑制 Tier-2 重编译，除非同时设置COMPLUS_ReadyToRun=0 - 调试器附加（如 VS 调试运行）：JIT 默认降级为 Tier-0 模式，不触发 PGO 升级
生产环境中最容易被忽略的一点：容器内存限制过低（如 memory: 128Mi）会导致 GC 频繁、JIT 线程被抢占，采样数据失真，最终使 PGO “学偏”。建议至少保留 512 MiB 以上可用内存供运行时调度。
