SWITCH语句只在调试或兼容模式下产生与if相同的程序集。在发布版中，它将被编译成跳转表(通过MSIL 'switch'语句)，即O(1)。

c#(不像许多其他语言)也允许打开字符串常量——这工作起来有点不同。为任意长度的字符串构建跳转表显然是不现实的，所以通常情况下，这样的切换将被编译成if堆栈。

但是如果条件的数量大到足以覆盖开销，c#编译器将创建一个HashTable对象，用字符串常量填充它，并在该表上进行查找，然后跳转。哈希表查找不是严格的O(1)，并且有明显的常量代价，但是如果大小写标签的数量很大，它将比在if中比较每个字符串常量快得多。

总而言之，如果条件数量超过5个左右，则优先选择SWITCH而不是if，否则使用任何看起来更好的方法。

SWITCH语句只在调试或兼容模式下产生与if相同的程序集。在发布版中，它将被编译成跳转表(通过MSIL 'switch'语句)，即O(1)。

c#(不像许多其他语言)也允许打开字符串常量——这工作起来有点不同。为任意长度的字符串构建跳转表显然是不现实的，所以通常情况下，这样的切换将被编译成if堆栈。

但是如果条件的数量大到足以覆盖开销，c#编译器将创建一个HashTable对象，用字符串常量填充它，并在该表上进行查找，然后跳转。哈希表查找不是严格的O(1)，并且有明显的常量代价，但是如果大小写标签的数量很大，它将比在if中比较每个字符串常量快得多。

总而言之，如果条件数量超过5个左右，则优先选择SWITCH而不是if，否则使用任何看起来更好的方法。

题外话，但我经常担心(更经常看到)if/else和switch语句用太多的情况变得太大。这些通常会损害可维护性。

常见的罪魁祸首包括:

在多个if语句中执行太多操作 案例陈述多得人类无法分析 if求值中的条件太多，以至于不知道要寻找什么

修复:

提取到方法重构。 使用带有方法指针的Dictionary而不是大小写，或者使用IoC来增加可配置性。方法工厂也很有帮助。 提取条件到自己的方法

根据这个链接，使用Switch和IF语句的迭代测试的IF和Switch比较，就像对于1,000,000,000次迭代，Switch语句花费的时间= 44.3秒，IF语句花费的时间= 48.0秒

也就是每秒20833333次迭代，所以，我们真的需要更专注吗，

附注:只是为了了解在少量条件下的性能差异。

switch语句肯定比if else if语句快。有速度测试，已经提供了对它的黑黄蜂

http://www.blackwasp.co.uk/SpeedTestIfElseSwitch.aspx

——看看吧

但很大程度上取决于你要考虑的可能性，但我尽量使用switch语句。

我认为，不只是c#，而是所有基于C的语言:因为切换仅限于常量，所以使用“跳转表”可以生成非常高效的代码。C用例实际上是一个很好的老式FORTRAN计算GOTO，但c#用例仍然是针对常量进行测试。

优化器不可能生成相同的代码。考虑,例如,

if(a == 3){ //...
} else if (a == 5 || a == 7){ //...
} else {//...
}

因为这些是复合布尔值，生成的代码必须计算一个值，然后短路。现在考虑一下

switch(a){
   case 3: // ...
    break;
   case 5:
   case 7: //...
    break;
   default: //...
}

这可以编译成

BTABL: *
B3:   addr of 3 code
B5:
B7:   addr of 5,7 code
      load 0,1 ino reg X based on value
      jump indirect through BTABL+x

因为你隐式地告诉编译器它不需要计算OR和相等测试。