r2r是需指定目标平台（-r）和自包含（--self-contained）的预编译策略，启用publishreadytoruncomposite可显著降低冷启动时间但增大体积，不兼容动态代码生成且调试体验下降。
ReadyToRun（R2R）不是“开箱即用的加速开关”，而是需要明确目标平台、接受体积代价、并绕过 JIT 依赖的预编译策略。它对冷启动敏感型场景有效，但对热路径密集型应用收益有限。
dotnet publish 里必须指定 -r 和 --self-contained 才能生效
R2R 编译依赖目标运行时环境（RID），dotnet publish 若未带 -r win-x64 或 -r linux-arm64 等 RID 参数，PublishReadyToRun 实际会被静默忽略——因为 CrossGen2 需要确切知道生成哪套本机指令集。
- 不指定
-r：发布出的仍是纯 IL 程序集，PublishReadyToRun=true不起作用 - 不加
--self-contained：即使 R2R 编译成功，运行时仍可能 fallback 到 JIT（尤其在无 .NET Runtime 的目标机器上） - 复合模式（
PublishReadyToRunComposite=true）强烈建议启用，它把所有依赖程序集合并为单个 R2R 映像，减少加载跳转开销
PublishReadyToRunComposite=true 是性能关键点，但会增大发布体积
默认单个程序集各自生成 R2R 映像，运行时需分别加载、解析、链接；启用 PublishReadyToRunComposite 后，CrossGen2 将主程序集及其所有直接/间接引用（含 NuGet 包）统一编译进一个映像文件，省去大量元数据解析和跨模块调用开销。
- 实测 Hyper-V 冷启动从 3100ms → 1420ms（下降 54%）
- 发布体积增加约 22%～28%，主要来自重复的类型元数据和调试符号冗余
- 若项目含大量条件编译（如
#if DEBUG）或运行时反射，复合模式可能因跨程序集内联失败而退化为非复合行为
R2R 不兼容动态代码生成，Expression.Compile() 和 Reflection.Emit 会直接报错
R2R 映像是静态本机代码 + 固定元数据，无法在运行时生成新方法体。一旦代码路径中存在 Expression.Compile()、DynamicMethod.CreateDelegate() 或任何 AssemblyBuilder 操作，应用会在首次调用时抛出 NotSupportedException: Dynamic code generation is not supported。
- 常见踩坑点：ORM（如早期 Entity Framework Core 动态查询）、JSON 序列化器（如 Newtonsoft.Json 的某些构造方式）、自定义 AOP 代理
- 替代方案：改用
System.Text.Json静态源生成（JsonSerializerContext），或显式标注[UnconditionalSuppressMessage]并配合 trimming root 声明 - 验证手段：发布后用
corflags MyApp.dll查看 Flags 是否含IL_ONLY（R2R 成功则应为32BITREQUIRED + ILOnly=0）
调试体验变差，符号和堆栈信息受限
R2R 映像中的调试信息是可选嵌入的，且仅支持 PDB 格式（不支持 portable PDB），VS 调试器在断点命中、局部变量查看、调用栈展开等环节表现弱于纯 IL 场景。
- 发布时加
/p:DebugType=portable无效，R2R 强制使用 Windows PDB 或 DWARF（Linux） - 堆栈帧中方法名可能显示为
MyApp!MyClass::MyMethod而非源码行号，尤其跨 R2R 边界调用时 - 若需调试，建议保留一份非 R2R 的 Release 发布包用于问题复现，生产环境再切 R2R 版本
真正难处理的不是配置开关，而是识别哪些代码路径隐式依赖 JIT —— 比如一个看似静态的 LINQ 查询，底层可能触发 Expression 树编译；又比如某个第三方 SDK 的初始化逻辑悄悄用了 Assembly.LoadFrom。这些只有在目标环境实际运行并捕获异常时才会暴露。
