好的，这只是出于好奇心，没有实际帮助。
我知道使用表达式树可以像常规C#编译器一样即时生成MSIL代码。由于编译器可以决定优化，我想问的是在Expression.Compile()期间生成的IL是否与调试模式和发布模式下的IL有所不同？主要有两个问题：
由于在编译时，编译器可以在调试模式和发布模式下生成不同（可能稍有不同）的IL，当在调试模式和发布模式下构建表达式时，生成的IL是否有所不同？
同时，JIT在运行时将IL转换为本机代码，而在调试模式和发布模式下应该会有很大的区别。编译表达式也是这种情况吗？或者说表达式树中的IL根本没有被转化成本地代码吗？
我的理解可能有误，如有错误请纠正。
注意：我考虑的是除去调试器的情况。我询问的是Visual Studio中默认配置设置中随附的“调试”和“发布”情况。
1 如果您曾经想知道为什么LINQ/DLR表达式如此严谨地要求准确的类型匹配，那是因为它们旨在作为多语言的编译器目标，每种语言都可能具有不同的方法绑定规则，隐式和显式类型转换等规则。因此，手动构造LINQ/DLR树时，必须完成编译器通常在幕后执行的工作，例如自动插入隐式转换的代码。
整数求平方。
我不确定这是否能够充分展示问题，但是我想到了以下的示例：
// make delegate and find length of IL:
Func<int, int> f = x => x * x;
Console.WriteLine(f.Method.GetMethodBody().GetILAsByteArray().Length);
// make expression tree
Expression<Func<int, int>> e = x => x * x;
// one approach to finding IL length
var methInf = e.Compile().Method;
var owner = (System.Reflection.Emit.DynamicMethod)methInf.GetType().GetField("m_owner", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance).GetValue(methInf);
Console.WriteLine(owner.GetILGenerator().ILOffset);
// another approach to finding IL length
var an = new System.Reflection.AssemblyName("myTest");
var assem = AppDomain.CurrentDomain.DefineDynamicAssembly(an, System.Reflection.Emit.AssemblyBuilderAccess.RunAndSave);
var module = assem.DefineDynamicModule("myTest");
var type = module.DefineType("myClass");
var methBuilder = type.DefineMethod("myMeth", System.Reflection.MethodAttributes.Static);
e.CompileToMethod(methBuilder);
Console.WriteLine(methBuilder.GetILGenerator().ILOffset);
结果:
在Debug配置下，编译时方法的长度为8，而发出的方法的长度为4。
在Release配置下，编译时方法的长度为4，而发出的方法的长度也为4。
在Debug模式下，由IL DASM查看的编译时方法:
.method private hidebysig static int32 '<Main>b__0'(int32 x) cil managed
{
.custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 )
// Code size 8 (0x8)
.maxstack 2
.locals init ([0] int32 CS$1$0000)
IL_0000: ldarg.0
IL_0001: ldarg.0
IL_0002: mul
IL_0003: stloc.0
IL_0004: br.s IL_0006
IL_0006: ldloc.0
IL_0007: ret
}
发布：
.method private hidebysig static int32 '<Main>b__0'(int32 x) cil managed
{
.custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 )
// Code size 4 (0x4)
.maxstack 8
IL_0000: ldarg.0
IL_0001: ldarg.0
IL_0002: mul
IL_0003: ret
}
Compile()总是带着“优化”进行？csc.exe生成的IL和由LINQ/DLR表达式树生成的IL，您无法得出任何有意义的结论：这里有两个完全独立的编译器在工作，并且它们执行的优化类型之间没有关系。C# Release模式下方法大小与LambdaCompiler生成的方法大小相匹配的事实是偶然的。所有这些都表明，对于一个微不足道的方法，当以Debug模式运行时，LambdaCompiler生成了更有效的IL，而C#编译器则没有。 - Mike StrobelLambdaCompiler执行的优化在项目构建配置方面是无关的，因此实际上是“始终启用”的。然而，与csc.exe执行的优化相比，LambdaCompiler执行的优化在任何情况下都是完全不同的。 - Mike Strobel正如其他答案所指出的那样，在运行时检测调试/发布并不是一件真正的“事情”，因为这是一个由项目配置控制的编译时决策，而不是在构建后的程序集中真正可检测的东西。运行时可以反射程序集上的AssemblyConfiguration属性，检查其Configuration属性 - 但对于.NET如此基础的东西来说，这将是一个不太精确的解决方案，因为该字符串实际上可以是任何内容。
此外，不能保证该属性存在于程序集中，并且由于我们可以在同一进程中混合使用发布/调试程序集，因此几乎不可能说“这是一个调试/发布进程”。
最后，正如其他人提到的那样，DEBUG != UNOPTIMISED——“可调试”汇编的概念更多地涉及惯例而非其他内容（反映在.Net项目的默认编译设置中），这些惯例控制PDB中的详细信息（顺便说一句，并不是PDB的存在与否），以及代码是否被优化。因此，可以有一个经过优化的调试汇编，也可以有一个未经优化的发布汇编，甚至可以有一个带有完整PDB信息的经过优化的发布汇编，它可以像标准的“调试”汇编一样进行调试。