MethodImplOptions.AggressiveInlining能否阻止未使用的昂贵参数求值？

哪怕给Log方法加上MethodImplOptions.AggressiveInlining做激进内联，只要传入的logLevel小于当前配置的chosenLogLevel，SlowFunction()依然会被完整执行，没有任何跳过的可能。

• 这个行为的决定因素根本不是内联优化策略，而是C#语言规范对方法参数求值的强制要求：在把控制权移交给被调用方法之前，所有作为实参的值必须被完整求值完成，和被调用方法内部的逻辑、编译器优化方式没有任何关系。
• AggressiveInlining的本质是让编译器把被调用方法的方法体代码，直接嵌入到调用位置，省掉方法调用本身的栈帧构建、指令跳转的固定开销，但它完全不会改动原本的代码执行语义。哪怕Log方法被完全内联展开，代码的执行流依然是先算完SlowFunction()的返回值，再执行Log方法内部的日志级别判断逻辑。

可以直观对比内联展开前后的执行逻辑：

// 原始调用写法
Log(SlowFunction(), someLogLevel);

// 被AggressiveInlining完全展开后，实际执行逻辑和下面的代码完全等价
// 第一步：先把两个实参全部计算完成
string message = SlowFunction();
LogLevel level = someLogLevel;
// 第二步：再执行原Log方法体的判断逻辑
if (level >= chosenLogLevel)
{
    Console.WriteLine(message);
}

哪怕编译器能明确看到日志级别不满足要求、SlowFunction()的计算结果根本不会被使用，它也不能随便把SlowFunction()的调用删掉。因为SlowFunction()完全可能存在副作用：比如修改全局状态、触发额外的资源操作、抛出可控异常，这些行为如果被随便跳过，会直接改变程序的最终执行结果，属于编译器绝对不敢随意突破的执行逻辑边界。

实际开发中如果要避免这种无意义的高开销计算，常用的方案有：

• 手动在调用层加前置判断：先确认当前日志级别满足输出要求，再去调用SlowFunction()生成日志内容，从源头上规避不需要的计算
• 调整Log方法的参数设计：把直接传入计算好的字符串，换成传入Func<string>形式的延迟求值委托，只有在确认需要输出日志时，才执行委托拿到日志内容
• 选用.NET内置的、基于插值字符串句柄做优化的日志框架，这类框架本身已经处理了不必要的高开销日志生成逻辑，不需要开发者手动重复写判断

内容的提问来源于stack exchange，提问作者markonius