企业官网建设流程全解析

写 Emit 写到大半夜，最让人怀疑人生的不是 OpCode 记不住，而是代码明明编译通过、运行时却甩你一句InvalidProgramException，连堆栈都不给。我见过太多人在ILGenerator的分支条件指令上栽跟头：标签没标记、短跳转越界、分支前后栈深度对不上、条件分支前少压了一个操作数。这几个坑几乎是每一个手写 IL 的人都要交的学费。这篇就把ILGenerator里以Br、Brtrue、Brfalse、Beq、Bne_Un、Bgt、Blt为代表的分支条件指令从头捋一遍，包括它们各自从求值栈上弹几个值、偏移量怎么算、_S短跳转的边界在哪、Switch跳转表怎么构造，以及怎么把一段if/else、while循环翻译成能跑的分支结构。适合已经能用DynamicMethod生成简单方法、但在控制流上卡住的读者，也适合想知道“C# 编译器到底把我的 if 编成了啥”的人对照着看。

1. 分支条件指令为什么值得单独拎出来讲

1.1 一段能跑和一段不能跑的分支 IL，差别在哪

很多人第一次写分支，逻辑上完全正确，跑起来却不是崩就是结果诡异。拿一个最简单的三分支判断举例：参数小于 0 返回 -1，等于 0 返回 0，大于 0 返回 1。用 Emit 写出来大概是这样，先看这段“能跑”的版本：

var dm = new DynamicMethod("Sign", typeof(int), new[] { typeof(int) }, typeof(Program).Module); var il = dm.GetILGenerator(); var lblZero = il.DefineLabel(); var lblNeg = il.DefineLabel(); il.Emit(OpCodes.Ldarg_0); il.Emit(OpCodes.Ldc_I4_0); il.Emit(OpCodes.Blt, lblNeg); // x < 0 跳到 lblNeg il.Emit(OpCodes.Ldarg_0); il.Emit(OpCodes.Ldc_I4_0); il.Emit(OpCodes.Beq, lblZero); // x == 0 跳到 lblZero il.Emit(OpCodes.Ldc_I4_1); // 剩下就是 x > 0 il.Emit(OpCodes.Ret); il.MarkLabel(lblZero); il.Emit(OpCodes.Ldc_I4_0); il.Emit(OpCodes.Ret); il.MarkLabel(lblNeg); il.Emit(OpCodes.Ldc_I4_M1); il.Emit(OpCodes.Ret); var f = (Func<int, int>)dm.CreateDelegate(typeof(Func<int, int>));

这段能跑，是因为它满足三个隐性约束：每条分支指令执行前，栈上已经压好了它需要的操作数；每个标签只被标记一次，且标记位置在一条完整指令的起始处；无论从哪个分支进入某个标签，到达该标签时的栈深度都相同——这里全是 0。

“不能跑”的版本通常坏在其中一条。比如Blt之前只压了一个Ldarg_0，少了一个比较对象，JIT 在验证阶段就会判定栈不平衡；比如DefineLabel之后忘了MarkLabel，CreateDelegate那一刻直接抛异常；比如分支跳到了Ldc_I4_0与Ret之间，落点不是指令边界，整个方法体的 IL 流被打乱。这三种错误报出来的异常信息都非常吝啬，几乎不会告诉你具体哪一行出问题，所以只能靠规则约束自己。

提示：分支目标必须是“指令起始位置”。MarkLabel要放在两条Emit之间，不要试图标记到某条指令的中间，也不要在MarkLabel之后再Emit半条指令的前缀操作码。

1.2 指令语义速览：谁弹栈、弹几个、跳到哪里

分支条件指令的共性很明确：它们都从求值栈顶取走若干个值做判断，满足条件就跳转到目标标签，不满足就顺序执行下一条指令（也就是所谓的 fall-through）。弄清“弹几个”这件事，是避免栈不平衡的第一道关。

这张表里有两个容易忽略的点。第一，Beq没有_Un变体，因为相等判断对无符号和有符号是同一回事，微软没理由再造一个指令；而Bne只有Bne_Un，没有不带后缀的Bne，想表达“不等于”就必须用Bne_Un，这是很多人第一次写 IL 时会踩的命名坑。第二，Blt在 C# 里对应的是<，但Ldarg_0压入的是 int32，被当成有符号数处理；如果你的参数语义上是uint，用Blt就会得到完全相反的结果，必须换成Blt_Un。

写分支前最好养成一个习惯：把要比较的两个值按顺序压栈，第一个压的是“左操作数”，第二个压的是“右操作数”。Blt的语义是“栈顶第二个 < 栈顶”。顺序反了，大于就变成小于，逻辑全反，而且不报错，只会静默给你错误结果，这种错误最难查。

1.3 ILGenerator 里分支指令的完整家族

OpCodes里跟分支相关的字段一共有三十来个，但按结构归类其实只有三组：无条件跳转（Br、Br_S）、条件跳转（Brtrue、Brfalse、Beq、Bne_Un、Bge、Bgt、Ble、Blt及各自的_Un、_S变体）、多路跳转（Switch）。

ILGenerator为这些指令提供了两个重载：

public virtual void Emit(OpCode opcode, Label label); public virtual void Emit(OpCode opcode, Label[] labels);

第一个用于单目标跳转，第二个只给Switch用。注意没有Emit(OpCode, int offset)这种重载，你不能直接写偏移量，必须通过Label让ILGenerator自己去算。这个设计其实很友好，因为手算偏移量在指令数量一多的时候几乎必错。

_S后缀的那批指令（Br_S、Brtrue_S、Beq_S等）在ILGenerator里跟长版本用法完全一样，区别只在生成的字节流长度和偏移量可表示范围。这也是我会在后面单独拿一节讲的原因：用错了不一定立刻报错，有时候是编译能过、运行时才炸。

2. 长跳转与 _S 短跳转：偏移量这件事必须算清楚

2.1 指令编码长度与偏移量的基准点

先明确一件事：IL 里的分支偏移量是相对“分支指令的下一条指令”计算的，不是相对分支指令本身，也不是相对方法体开头。这个基准点记错，所有手工推导都会偏。

长跳转编码是 1 字节操作码加 4 字节有符号偏移，共 5 字节；短跳转是 1 字节操作码加 1 字节有符号偏移，共 2 字节。Switch比较特殊，编码是 1 字节操作码、4 字节表长度 N、再跟 N 个 4 字节偏移，总长1 + 4 + 4N。

假设某条Br_S指令位于方法体偏移 P 处，那么它的下一条指令位于P + 2。如果目标标签标记在偏移 T 处，则写入的偏移值就是T - (P + 2)。这个值必须落在 sbyte 的范围内，也就是 -128 到 127。

长跳转的算法一模一样，只是结果用 int32 存，范围是 ±2GB，实际上不可能超。

ILGenerator内部维护一个 IL 流和一个标签修正列表。每当你Emit一条带标签的分支指令，它就把这条指令的位置和标签 ID 记下来；每当你MarkLabel，它就把标签当前位置记录下来。等所有指令都写完、调用CreateDelegate或者GetMethodBody的时候，它再统一回填所有偏移量。这个延迟回填的机制意味着：你在中途是看不到真实偏移的，标签没标记之前也不会立刻报错。

2.2 短跳转 127 字节边界的手工验证

我拿一段实际代码验证过一次边界。构造一个方法，先Br_S跳过一段填充指令，填充部分的字节数刚好控制在 125、126、127 三档，观察行为。

var dm = new DynamicMethod("T", typeof(void), Type.EmptyTypes); var il = dm.GetILGenerator(); var target = il.DefineLabel(); il.Emit(OpCodes.Br_S, target); // 2 字节，位置 0，下一条在位置 2 // 下面填充若干 ldc.i4 + pop 组合，每条 2 字节 for (int i = 0; i < 63; i++) { il.Emit(OpCodes.Ldc_I4_0); il.Emit(OpCodes.Pop); } il.MarkLabel(target); il.Emit(OpCodes.Ret);

63 组填充是 126 字节，加上Br_S自身的 2 字节，目标位置在 128，相对下一条指令（位置 2）的偏移是 126，正好在 127 的上限之内，能过。把循环次数改成 64，偏移变成 128，超出 sbyte 上限，CreateDelegate阶段会抛异常。

实际测试里异常类型在不同运行时版本上有差异，有的是ArgumentException，有的是InvalidOperationException，消息也不统一。所以我的建议很直接：除非你在做指令编码分析工具，否则永远用长跳转版本。那点字节数在绝大多数场景下毫无意义，省下来的调试时间够你把整个模块写完。

注意：短跳转越界不是“自动升级成长跳转”，ILGenerator不会帮你做这个决策。你写的是Br_S，它就生成Br_S，超范围就报错。

2.3 默认选长跳转的理由

理由有三个，按重要性排。

第一是稳定性。长跳转的偏移量是 int32，方法体再大也很难超过 2GB，实际上可以认为永不越界。用它换来的确定性远比省 3 个字节划算。

第二是可读性和可维护性。一段一百多行的 Emit 代码，中间夹着一堆_S后缀，读代码的人要不停在脑子里算“这段够不够短”，心智负担极高。统一用长版本，代码风格一致，改动时也不用担心插入几行就把某条短跳转顶出边界。

第三是跟编译器产物对照的便利。你反编译 C# 编译出来的 IL，会看到大量br.s、brtrue.s，那是 Roslyn 在生成时做的优化，它有能力精确计算偏移。但你手动跟它对抄的时候，如果混着用，很容易把偏移算错。我自己是先用长跳转把逻辑跑通，功能验证完毕，再去考虑要不要在某些热点路径上换短跳转——而实际上从来没换过。

3. 标签体系：DefineLabel 与 MarkLabel 的正确用法

3.1 Label 是占位符，不是地址

Label是一个值类型（结构体），内部包着一个 int 标识，本质上是ILGenerator内部标签表的下标，不是什么内存地址或者偏移。DefineLabel()做的事情就是从标签表里分配一个新 ID，返回给你，此时这个标签还没有位置。

真正的定位发生在MarkLabel(Label)调用时，ILGenerator把当前 IL 流的长度记录到这个标签上。之后所有引用这个标签的分支指令，在回填阶段都会拿到这个位置。

这里有个细节值得强调：DefineLabel和MarkLabel之间可以隔任意多条指令，甚至可以在方法开头定义、方法结尾标记。一个标签只能标记一次，重复标记会抛异常。但一个标签可以被任意多条分支指令引用，这是完全合法的，也是实现if/else汇聚点的常用手法。

var end = il.DefineLabel(); // 分支 A 跳到 end il.Emit(OpCodes.Br, end); // 分支 B 也跳到 end il.Emit(OpCodes.Br, end); il.MarkLabel(end); // 只标记一次 il.Emit(OpCodes.Ret);

这段代码虽然逻辑上第二条Br不可达，但 IL 结构本身是合法的，JIT 不会拒绝。

3.2 合法跳转边界：能不能跳进 try 块

这是分支指令里最容易出事、也最少被人提前告知的一条规则：你不能从 try 块外部跳进 try 块内部。异常处理块在 IL 层面有严格的区域划分，try、catch、finally、fault、filter各自构成独立的保护区域，跨区域跳入是非法的，JIT 会直接抛InvalidProgramException。

可以做的事有：从 try 块内部跳到 try 块外部（这叫“离开保护区”，C# 里对应leave指令，不是br）；在同一个块内部任意跳转；从 try 块跳到它自己的开头（形成循环）。不可以做的事：从外部跳进 try 的中间；从一个 catch 块跳进另一个 catch 块；跳进 finally 块的中间。

如果你用ILGenerator的BeginExceptionBlock/BeginCatchBlock/EndExceptionBlock系列方法，ILGenerator会帮你处理leave指令和区域边界，但你手动Emit(OpCodes.Br, label)时它不会替你检查。所以涉及异常处理的分支，我一律建议在同层区域内解决，跨层跳转交给ILGenerator的封装方法。

3.3 标签相关的三类典型错误

第一类是“标签未标记”。DefineLabel之后忘了MarkLabel，代码能编译、能执行到CreateDelegate之前的所有语句，然后在创建委托那一刻抛异常。这种错误最难定位，因为抛异常的位置跟你写错的位置可能隔着几百行。

第二类是“标签标记位置不对”。比如这样写：

il.MarkLabel(lbl); il.Emit(OpCodes.Ldc_I4_5);

这没问题。但如果你写成：

il.Emit(OpCodes.Ldc_I4_5); il.MarkLabel(lbl); il.Emit(OpCodes.Pop);

那么跳转过来时栈顶是空的，Pop就会让栈深度变成负数，JIT 直接判定非法。标记位置的判断标准是：跳到这个标签时，栈的状态必须与顺序执行到这里时的状态一致。

第三类是“标签复用到不同栈深度”。同一个标签被两处引用，但两处跳转前压栈的数量不同，那么到达标签时栈深度就取决于来路，这在 IL 验证里是不允许的。解决方式是分设标签，或者在跳转前把栈收拾干净。

4. 条件分支逐条拆解与组合套路

4.1 Brtrue / Brfalse：把任意值当布尔用

Brtrue和Brfalse是这对指令里语义最宽泛的。它们接受 int32、int64、native int 或者对象引用，判断规则是：整型看是否为零，引用类型看是否为 null。这个“看是否为零/null”的语义，正好对应 C# 里if (x)和if (obj != null)两种写法。

用它们可以把很多条件判断简化。比如判断一个引用参数是否为 null：

il.Emit(OpCodes.Ldarg_0); il.Emit(OpCodes.Brfalse, lblNull); // 非 null 分支

不用先Ldnull再Ceq，一条Brfalse就够了，省一条指令，也省一次栈操作。

但有个明确的坑：浮点值不能直接喂给Brtrue/Brfalse。这条指令的栈类型约束里没有 float32 和 float64。想让一个 double 参与条件判断，必须先转成整型或布尔。标准做法是：

// 判断 d != 0 il.Emit(OpCodes.Ldarg_0); // double il.Emit(OpCodes.Ldc_R8, 0.0); il.Emit(OpCodes.Ceq); // 相等则 1 il.Emit(OpCodes.Ldc_I4_0); il.Emit(OpCodes.Ceq); // 再取反，得到 d != 0 il.Emit(OpCodes.Brtrue, lblNotZero);

或者用Cgt_Un配合Ldc_R8，见 4.4 节。总之浮点必须绕一道。

Brtrue/Brfalse还有一个实用场景：配合Ceq、Cgt、Clt三条比较指令构建“先算布尔再分支”的模式。C# 编译器大量采用这种模式，因为它把比较和跳转解耦，方便做短路求值。

4.2 Beq / Bne_Un：相等与不等比较

Beq是“相等则跳转”，Bne_Un是“不等则跳转”。注意后者强制按无符号比较，但因为相等性对符号位不敏感，所以实际语义就是“不等”。

这两条指令要求两个操作数类型一致。都是 int32、都是 int64、都是 native int、都是对象引用、都是 float32 或 float64，混着来就是非法 IL。比如Ldc_I4_1之后跟一个Ldc_I8再用Beq，JIT 会拒绝。解决方式是先用Conv_I8把小的转成大的。

il.Emit(OpCodes.Ldarg_0); // int32 il.Emit(OpCodes.Conv_I8); il.Emit(OpCodes.Ldc_I8, 100L); // int64 il.Emit(OpCodes.Beq, lblHit);

对浮点数用Beq时要注意 NaN：按 IEEE 754 规则，NaN 不等于任何值，包括它自己。所以Beq遇到 NaN 一定不跳。如果你写的是if (d == d)，用Beq会得到“永远不跳”的结果，而 C# 语义下double.NaN == double.NaN是 false，两者其实一致。但反过来，如果你的逻辑要求“NaN 进入某个分支”，用Beq就实现不了，得用Ceq加取反。

4.3 Bgt / Bge / Blt / Ble 与 _Un 变体

这四条是大小比较，各有有符号和无符号两个版本。选哪个版本取决于你在心算时把操作数当成什么类型。

// int 语义：x > 10 il.Emit(OpCodes.Ldarg_0); il.Emit(OpCodes.Ldc_I4, 10); il.Emit(OpCodes.Bgt, lblBigger); // uint 语义：x > 10u il.Emit(OpCodes.Ldarg_0); il.Emit(OpCodes.Ldc_I4, 10); il.Emit(OpCodes.Bgt_Un, lblBigger);

看起来只差一个后缀，但在x = 0xFFFFFFFF（也就是 -1 的位模式）时，第一条判断为 false（-1 不大于 10），第二条判断为 true（4294967295 大于 10）。这种差异在写序数计算、哈希分区、位掩码处理时会要命。

除了整数，Blt.Un和Bgt.Un还专门用于比较托管指针和原生指针。C# 里pointer1 < pointer2就编译成blt.un。如果你在做指针运算相关的 Emit，记得用无符号变体。

一个容易顺手写错的地方是比较顺序。Blt的语义是“栈顶第二个 < 栈顶”，所以：

il.Emit(OpCodes.Ldarg_0); // 左 il.Emit(OpCodes.Ldarg_1); // 右 il.Emit(OpCodes.Blt, lbl); // arg0 < arg1

写反了就变成arg1 < arg0。这个错误不会报任何异常，只会让分支在完全相反的输入下触发。我的习惯是先把 C# 表达式原样写出来，再把两边操作数按书写顺序压栈，最后选对应的指令，绝不凭记忆直接写。

4.4 浮点比较为什么建议绕道 cgt.un

处理浮点数时，直接用Bgt、Bge之类的分支指令在 NaN 参与时会得到奇怪结果。IL 规范对浮点分支的 NaN 处理有明确但反直觉的定义：bge遇到 NaN 时不跳转，ble遇到 NaN 时也不跳转，除非使用.un版本。这套规则跟 C# 的>=、<=语义并不完全一致，照抄容易出偏差。

更稳的写法是先算出布尔，再用Brtrue/Brfalse。这个模式在 C# 编译器里也是主流：if (a >= b)对 double 通常编译成clt.un（或cgt.un）加brfalse。

// if (a >= b)，即 !(a < b)，且 NaN 时结果为 false il.Emit(OpCodes.Ldarg_0); // a il.Emit(OpCodes.Ldarg_1); // b il.Emit(OpCodes.Clt_Un); // a < b ? 1 : 0（NaN 时返回 1） il.Emit(OpCodes.Brtrue, lblSkip); // 若 a < b（含 NaN）则不进入分支 // 进入这里说明 a >= b 且非 NaN

Clt_Un和Cgt_Un的“un”在这里不是“无符号”的意思，而是“无序比较”（unordered），遇到 NaN 一律返回 true。Clt和Cgt遇到 NaN 返回 false。理解这一层，就能准确控制 NaN 落到哪个分支。

4.5 Switch：跳转表的构造与默认分支

Switch是唯一的非条件跳转指令，它从栈上弹出一个 uint32，如果这个值小于跳转表长度 N，就跳到表中对应位置；否则顺序执行下一条指令。注意它没有“默认分支”参数，默认行为就是 fall-through，所以惯例是在Switch之后紧跟一条Br指向默认标签。

var cases = new Label[3]; for (int i = 0; i < cases.Length; i++) cases[i] = il.DefineLabel(); var defaultLbl = il.DefineLabel(); il.Emit(OpCodes.Ldarg_0); // int32，会被当作 uint32 使用 il.Emit(OpCodes.Switch, cases); il.Emit(OpCodes.Br, defaultLbl); il.MarkLabel(cases[0]); il.Emit(OpCodes.Ldc_I4, 100); il.Emit(OpCodes.Ret); il.MarkLabel(cases[1]); il.Emit(OpCodes.Ldc_I4, 200); il.Emit(OpCodes.Ret); il.MarkLabel(cases[2]); il.Emit(OpCodes.Ldc_I4, 300); il.Emit(OpCodes.Ret); il.MarkLabel(defaultLbl); il.Emit(OpCodes.Ldc_I4_M1); il.Emit(OpCodes.Ret);

这里有个很实用的性质：因为弹出值按 uint32 解释，负数会变成 0x80000000 以上的大数，自动落到默认分支，不需要额外判断。如果你的 switch 键是-1到2这种小负整数范围，可以先把值加上偏移再Switch，比写五条Beq快得多。

Switch的编码长度是1 + 4 + 4N，表长本身占 4 字节，所以 1 个分支的Switch反而比Beq长。一般分支数超过 3 个时Switch才划算，这也是 C# 编译器选择跳转表还是链式比较的阈值参考。

5. 手写一个带多重分支的 Emit 方法

5.1 目标 C# 代码与 IL 草稿对照

目标逻辑：给定月份数（1–12），返回该月天数（简化处理，2 月固定 28 天，不处理闰年）。用 switch 实现最直观：

static int DaysInMonth(int m) { switch (m) { case 2: return 28; case 4: case 6: case 9: case 11: return 30; default: if (m >= 1 && m <= 12) return 31; return -1; } }

翻译成 IL 的思路分三段。第一段用Switch做主要分派，把 1–12 压缩成 12 个标签：值等于 2 的去 28 天标签，值等于 4、6、9、11 的去 30 天标签，其余去 31 天标签。第二段处理越界：Switch弹出的值如果不在 1–12 范围内，会跳到默认标签，在那里做上下界判断。第三段是各个返回分支。

这里有个细节要想清楚：Switch的索引是 0 基的，而我们用的是 1 基月份。解决办法是先减 1，构造 12 长的标签数组，数组下标 i 对应月份 i+1。

5.2 完整代码与逐行说明

var dm = new DynamicMethod("DaysInMonth", typeof(int), new[] { typeof(int) }, typeof(Program).Module); var il = dm.GetILGenerator(); var monthLabels = new Label[12]; for (int i = 0; i < 12; i++) monthLabels[i] = il.DefineLabel(); var lbl28 = il.DefineLabel(); var lbl30 = il.DefineLabel(); var lbl31 = il.DefineLabel(); var lblInvalid = il.DefineLabel(); // 计算 switch 键：m - 1 il.Emit(OpCodes.Ldarg_0); il.Emit(OpCodes.Ldc_I4_1); il.Emit(OpCodes.Sub); il.Emit(OpCodes.Switch, monthLabels); il.Emit(OpCodes.Br, lblInvalid); // 超出 1..12 范围 // 12 个月各自跳向对应的天数标签 for (int i = 0; i < 12; i++) { il.MarkLabel(monthLabels[i]); int month = i + 1; if (month == 2) il.Emit(OpCodes.Br, lbl28); else if (month == 4 || month == 6 || month == 9 || month == 11) il.Emit(OpCodes.Br, lbl30); else il.Emit(OpCodes.Br, lbl31); } il.MarkLabel(lbl28); il.Emit(OpCodes.Ldc_I4, 28); il.Emit(OpCodes.Ret); il.MarkLabel(lbl30); il.Emit(OpCodes.Ldc_I4, 30); il.Emit(OpCodes.Ret); il.MarkLabel(lbl31); il.Emit(OpCodes.Ldc_I4, 31); il.Emit(OpCodes.Ret); il.MarkLabel(lblInvalid); il.Emit(OpCodes.Ldc_I4_M1); il.Emit(OpCodes.Ret); var f = (Func<int, int>)dm.CreateDelegate(typeof(Func<int, int>));

逐段看。Ldarg_0压入月份，Ldc_I4_1压入 1，Sub弹两个压一个差值，此时栈顶是m-1。Switch弹掉它，按值分派。这里Sub之后栈深度回到 0，Switch又弹一个，净变化是 -1，属于“压一弹一”，平衡。

12 个标签依次标记，每个标签后面只放一条Br。这段看起来冗余，但结构清晰，而且方便后续扩展——如果哪天要加上“某些月份有不同天数”的逻辑，只需在对应标签后插入指令，不用重排整个跳转表。

最后四个返回分支各自压常量、Ret，栈行为一致，互不干扰。

5.3 验证与对照编译器输出

跑一遍验证：1 月应得 31，2 月 28，4 月 30，11 月 30，13 和 0 应得 -1。同时把等价的 C# 代码编译后反编译看 IL，会发现编译器大概率不会生成 12 项的Switch，而是用一系列Sub、Sub之后接Switch，或者干脆用比较链。差异原因在于 Roslyn 的跳转表阈值和分组策略，跟我们的目标不同，不用强求一致。

更值得对照的是“越界处理”这一段。编译器通常会先做范围检查，再进Switch；我们这里依赖Switch的 fall-through 行为处理越界，代码更短，但语义上有一点微妙差别：如果m是负数，m-1会下溢成一个很大的 uint32，同样落到默认分支，结果一样。这种“利用无符号语义”的技巧在 IL 里很常见，但前提是你得确定输入值类型是 int32，不会被隐式转成 int64。

注意：如果参数类型换成long，Switch就不适用了，因为它只接受 uint32。这时候只能先用Conv_I4截断（有溢出风险），或者退回Beq链。选跳转表之前先看操作数类型，这个检查能省掉不少返工。

6. 分支相关异常排查速查

6.1 InvalidProgramException 的几种成因

InvalidProgramException是手写 IL 最常见的报错，没有堆栈，没有行号，只说方法体非法。跟分支有关的成因主要有这几类：

其中“分支后栈深度不一致”是最隐蔽的一类。我的排查办法是在纸上画一张表，左列是指令序号，中间列是执行完这条指令后的栈深度，右列是注释。凡是跳到同一个标签的路径，最终栈深度必须相同。这个方法笨但有效，尤其是分支超过五条的时候，靠脑子记迟早出错。

6.2 排查流程与工具

遇到分支问题，我一般按这个顺序走。

第一步，把生成的 IL 打印出来。DynamicMethod可以用GetMethodBody()拿到MethodBody对象，进而取GetILAsByteArray()得到字节流，配合System.Reflection.Emit.OpCodes的字典反查操作码，能还原出可读的指令列表。自己写个小工具或者用现成的反编译库都行。

第二步，对照 C# 编译产物。把等价逻辑写成普通方法，编译后用反编译工具看 IL。不是说抄它的指令序列，而是看它怎么处理标签、怎么处理栈平衡、怎么选择有符号版本。编译器不会生成非法 IL，它是最好的参照物。

第三步，二分注释。如果方法体很长，把后半段的Emit全注释掉，改用Ldc_I4_0加Ret占位，看是否还报错。逐步放开，定位到具体哪一段引入了问题。这个方法在方法体超过 200 条指令时几乎是唯一的出路。

第四步，简化输入。分支逻辑错误有时候只在特定输入下暴露，这时候用最小的输入跑一遍，比如全 0 参数、全 1 参数，往往能快速暴露压栈顺序或者符号问题。

还有个小技巧：写 Emit 的时候开一个#if DEBUG块，在里面维护一份“期望的栈深度”变量，每Emit一条指令就更新一次，并在分支处断言两条路径的深度相等。虽然啰嗦，但比事后调试省时间得多，尤其是在同时维护十几个动态方法的时候。

最后分享一个我踩过好几次的坑：ILGenerator在Emit一条分支指令时，如果目标标签还没标记，它不会报错。这意味着你可以把MarkLabel写在整个方法体的任何一个位置，甚至写在所有分支指令之后。但如果中间有一次BeginExceptionBlock/EndExceptionBlock，标签的归属区域可能会发生变化，MarkLabel落在错误的保护区域内，报错信息会指向完全无关的地方。所以涉及异常处理块时，我现在的做法是每个标签定义完就紧跟着写它的标记位置（哪怕先留空占位），把距离压到最短，出问题时一眼就能看出是哪个标签的问题。