C#编译器为何对字符串与整数switch表达式采用不同优化策略？

我在C#中编写了两个使用switch表达式的方法，分别处理整数和字符串类型：

public int Int(int value)
{
    int sum = value switch
    {
        0 => 0,
        1 => 1,
        2 => 2,
        _ => throw new System.Exception()
    };
    return sum;
}

public int String(string value)
{
    int sum = value switch
    {
        "0" => 0,
        "1" => 1,
        "2" => 2,
        _ => throw new System.Exception()
    };
    return sum;
}

在Release模式（C# 12）下的反编译代码如下：

// Integer method
public int Int(int value)
{
    switch (value)
    {
        case 0:
            return 0;
        case 1:
            return 1;
        case 2:
            return 2;
        default:
            throw new Exception();
    }
}

// String method
public int String(string value)
{
    if (!(value == "0"))
    {
        if (!(value == "1"))
        {
            if (value == "2")
            {
                return 2;
            }
            throw new Exception();
        }
        return 1;
    }
    return 0;
}

我查看了IL及汇编代码，发现整数switch使用跳转表，而字符串switch依赖字符比较。通过BenchmarkDotNet测试发现字符串方法性能更优，手动将整数方法改为if链后性能也显著提升。我想了解：为何C#编译器选择将字符串switch表达式优化为if链，却不为整数switch表达式应用类似优化？希望能获知这些不同优化策略背后的原理。

1. 整数switch跳转表的设计初衷 #

跳转表是编译器针对整数范围连续、分支数量较多的场景设计的优化方案：它能通过计算偏移量直接跳转到对应分支，理论上分支数量越多，跳转表的优势越明显（时间复杂度接近O(1)）。对于你这种仅3个分支的场景，跳转表的额外开销（比如计算偏移、表地址查找）会抵消它的优势，甚至比if链慢——但编译器的优化策略是基于通用场景制定的，不会针对极小分支数做特殊适配，因为大部分整数switch的分支数量远多于3个。

2. 字符串switch无法使用跳转表的核心原因 #

字符串本质是引用类型，无法像整数那样直接映射到连续的内存偏移。早期C#版本曾尝试对字符串switch做哈希表优化，但哈希冲突、字符串比较的额外开销（比如长度检查、逐字符比对）让这种方案的收益不稳定。最终编译器选择了if链优化：

• 对于短字符串（像你例子中的单字符字符串），逐字符比对的开销极小
• if链的分支预测命中率更高（现代CPU的分支预测器对线性if链的预测准确率远高于跳转表或哈希表）
• 避免了哈希表的初始化、内存分配等额外成本，在分支数较少时优势显著

3. 编译器优化的权衡逻辑 #

编译器的优化策略不是追求某一极端场景的最优，而是平衡通用性能和实现复杂度：

• 整数switch的跳转表在分支数≥5-6时性能会超过if链，这是更常见的使用场景，所以编译器默认生成跳转表
• 字符串switch的跳转表/哈希表方案在分支数少、字符串短的场景下收益极低，甚至不如if链，因此编译器选择了更适配常见字符串switch场景的if链优化

如果你需要针对极小分支数的整数switch做极致优化，可以手动改成if链——但编译器不会默认这么做，因为这会牺牲多数场景下的性能。

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