switch和if哪个效率高：看分支数量

switch和if哪个效率高，核心判断逻辑：分支数量小于4时，两者性能差距很难被测出，优先用if；分支数量大于等于4且是常量等值判断，switch大概率更快，编译器会把符合条件的switch编译成跳转表，单次查找开销接近固定值，而if是顺序逐个判断，分支越多平均耗时越高。该结论适用于C、C++、Java、Go这类编译型/带JIT的主流语言，不适用于Python这类没有原生switch语法的动态语言，动态语言的分支判断机制和编译型语言差异明显，不能套用这套性能判断方式。你做性能评估时，不能只凭理论推断，要在目标编译选项、目标硬件环境下写基准测试代码，很多现代编译器会自动优化简单if串，优化后两者执行耗时会变得十分接近。

switch和if底层执行机制

if语句采用顺序比较模式，代码会从上到下依次执行条件判断，只要前面条件成立，后面的判断就不再执行。当命中分支刚好在判断链末尾，程序就要走完全部条件，最坏耗时随分支数量线性增长。比如你写6层连续ifelse，目标值匹配最后一个分支，程序需要依次对比前面5个条件，才会进入最终逻辑。

switch在满足条件时，编译器生成跳转表，跳转表本质是一个索引数组，程序拿到表达式结果，直接当做数组下标定位目标代码地址，跳转操作耗时基本固定，不会随分支数量增加而明显上涨。只有分支值不连续、跨度很大时，编译器放弃跳转表，退化成等价的ifelse链式判断，此时switch不再具备性能优势。

编译器优化会抹平性能差异。现代编译器如GCC、Clang，开启O2优化级别后，能把短的ifelse常量等值分支优化成跳转表，这种场景下switch和if运行效率基本一致。很多开发者实测3个分支以内，优化后的代码运行耗时波动在误差范围内，区分不出快慢。

switch和if场景对比

可读性不能为性能让步。分支数量多、仅做等值匹配时，switch结构更整齐，后续维护修改分支逻辑不容易出错。if更灵活，支持大于、小于、复合逻辑条件，适合条件不是简单等值的业务逻辑。不要为了追求微小性能提升强行改写代码，可读性差的代码会带来更高的后期维护成本。

性能差异大多只在高频循环场景才有意义。只有这段分支代码每秒执行数百万次，属于程序热点路径，你才需要关注switch和if的效率差别。普通业务代码，单次调用或者调用频次很低，两者耗时差异完全感知不到，优先选择可读性强的写法。

判断条件为浮点数、字符串时，C、C++的switch不支持这类类型，只能使用if。Java支持字符串switch，但底层依然是调用hash方法，存在哈希冲突的可能性，此时性能优势会减弱，不能简单套用常量整型的性能结论。

分支预判会改变实际运行耗时。如果业务里大概率命中前面的if分支，ifelse的实际平均耗时会很低，甚至优于跳转表形式的switch。跳转表每次都要做一次索引计算，少量分支场景下这个固定开销会抵消它的优势。

不要靠主观猜测性能，写微基准测试验证。你可以把两种写法封装成独立函数，循环百万次，统计运行时间。测试时关闭调试模式，使用项目正式编译参数，调试模式下编译器优化被关闭，测试结果不能代表线上真实运行表现。