MethodImplOptions.AggressiveInlining 仅是 JIT 编译器提示，不保证内联；是否生效取决于函数大小、异常处理、可见性、构建配置（仅 Release 有效）及代码结构，滥用反而降低性能。
在 C# 中，MethodImplOptions.AggressiveInlining 不是“内联方法”，它只是一个编译器提示特性，不能保证函数一定被内联——最终是否展开，完全由 JIT 编译器在运行时决定。盲目加这个特性反而可能破坏内联启发式判断，导致性能下降。
为什么 [MethodImpl(MethodImplOptions.AggressiveInlining)] 有时没效果
JIT 编译器有一套复杂的内联策略：函数体大小、调用深度、是否有异常处理块、是否含虚拟调用、是否跨程序集等都会影响判断。即使打了 AggressiveInlining，只要 JIT 认为不安全或不划算，就会忽略它。
-
AggressiveInlining只对 JIT 生效，对 AOT（如 .NET Native 或 CoreRT）或提前编译场景无效 - 函数含
try/catch、yield return、async/await时，JIT 几乎必然拒绝内联 - 目标方法若定义在另一个程序集且未启用
InternalsVisibleTo或未标记public，JIT 可能因可见性限制放弃内联 - Debug 模式下 JIT 默认禁用大部分内联（包括
AggressiveInlining），必须用 Release 配置 + 优化开启才可能生效
AggressiveInlining 的正确使用场景
它只应在极少数、已确认为性能瓶颈的热路径上使用，且函数满足 JIT 内联基本门槛：无分支逻辑、无对象分配、无非直接调用、纯计算型、小于 ~32 IL 字节（经验阈值）。
- 典型适用：坐标转换、位运算包装、简单数值校验（如
IsPowerOfTwo(int)） - 不适用：任何含
if多于 2 个分支、调用其他方法（尤其是虚方法）、访问字段或属性（除非是readonly字段）的函数 - 验证是否真正内联：用
dotnet-trace+Microsoft-Windows-DotNETRuntime/JitInlining事件，或反编译生成的汇编（dotnet-dump+dumpil/disasm）
比加特性更关键的三件事
真正影响内联成功率的，不是你写了什么特性，而是代码结构和构建配置。
- 确保发布构建启用了优化：
dotnet build -c Release --no-self-contained，且项目文件中未设<tieredpgo>false</tieredpgo>或<publishtrimmed>true</publishtrimmed>（后者会干扰 JIT 分析） - 避免在泛型方法上滥用
AggressiveInlining：JIT 对每个闭包类型单独判断，复杂泛型可能让内联失败率陡增 - 不要给
virtual或override方法加该特性——JIT 在非密封类型上几乎从不内联虚调用，除非能证明调用目标唯一（如 sealed class + final override）
最常被忽略的一点：AggressiveInlining 是“最后一公里”微调，不是性能银弹。95% 的内联收益来自写小而直白的函数 + 合理的调用链设计，而不是堆特性。一旦函数体开始增长或逻辑变重，删掉这个特性往往比留着更稳。
