为什么很多程序员不用switch，而是大量的ifelseif？

　　我个人觉得switch其实非常多余。
　　1 大部分场景，都是2到3个可能分支，用个if else就可以了，除非有4 个以上分支，太多else显得不好看，才考虑用switch.
　　2 switch限制多。switch必须是常量变量。if后面可以写任意表达式。
　　3用法复杂，case后面要么break,要么return,要是不写，居然还会继续执行剩下的分支，对于新手来说分分钟掉坑。
　　4 写法上其实也不比if else优雅简洁，switch xxx  case  xxxx ….
　　所以，switch徒增复杂性，真的不怎么实用。
　　如果有10000种switch的可能性，有1000000个值需要被处理，怕是你们说的这些个switch的好处就完全消失了，预期平均每次要比较5000次，1000000个值，总计要比较50亿次，不知道你们的CPU是啥主频能扛得住这个计算量，针对这种情况的终极武器还是hash，根据不同的语言，hash的value可以是匿名函数，可以是接口的不同实现，用hash来快速确定处理算法，而不是switch
　　答案：主要因为switch不适合业务系统的实际复杂需求，业务不断的变更迭代，一更改需求，条件的复杂度高了，switch无力处理。
　　switch优点
　　那么什么时候适合switch，它的场景是：基于单一变量的值（如枚举），这样的可读性比if条件更清晰。
　　switch缺点
　　从上面的场景来看，实在太局限，我来简单说一下它的一些缺点吧：
　　1. 现实的业务场景很复杂，条件不单一，一旦需求变更，维护代码相当崩溃。
　　2. switch经常忘记写break，估计很多人一不小心就忘记写了。如果你看过google的代码规范，你会发现，Google对switch的要求非常多。
　　switch的封装才更灵活
　　其实switch有人还在用也有一部分是历史原因，但是随着科技的发展，原有的设计以及落后了。
　　有些编程语言，如Python都没有switch这种语法。当然也有部分新语言Golang和Kotlin还是继承下来，但是又把switch包装了一下，去掉了令人误会的语法，这才让switch变得灵活起来了。 如果不封装，很难用。
　　IF语句的好处
　　通过上面描述的缺点也就是if语句更灵活的地方，根据业务进行逻辑条件编写，可维护性高。同时只要写的代码质量高，可读性也就会更高。
　　建议
　　现实的业务实际是很复杂的，我也不建议一定要用大量的if……else if,而是应该尽早返回来减少嵌套，这样增加了可读性以及降低维护的成本。
　　这个问题其实非常简单，其核心问题，一是，if/else if更能精准地表达一种判断，可以附带更多的关系式，使得程序表达更清晰；二是，软件要处理的逻辑关系大多很复杂，往往需要几个、甚至十几个关系式部分或者同时为TRUE时，才执行某一程序。
　　而switch只能对一个变量进行判断，只能表达简单的逻辑，不实用。if/else用于处理复杂的逻辑关系
　　比如，在处理一个自制的小手控盒，有X，Y，U，V，+，-等按钮，当同时按下X，+/-或者Y，+/-时执行子程序PXY（），当同时按下U，+/-或者V，+/-时执行子程序PUV（），这时必须用if/else：
　　if((k1==＂X＂)||（k1==＂Y＂)）&&（(k2==＂+＂）||（k2==＂-＂))
　　PXY（k1,k2）;
　　else if((k1==＂U＂)||(k1==＂V＂))&&（(k2==＂+＂）||（k2==＂-＂))
　　PUV（k1,k2）;
　　......
　　简短而准确、明了，而且非if/else莫属。残们实际写程序时，if后面的关系式往往要写近十行，为什么呢？逻辑关系太过复杂。比如以上的运动，要考虑主电源是否打开？指定的电机是否准备好？有无报警？是否已在限位？是否超出了工作区域？是否有其它按键？系统有无其它紧急报警？等等，都要考虑到，否则就会有重大事故发生。
　　如果在这种复杂逻辑关系场合，用switch，基本是不可能的。
　　在程序中什么时候用switch比较好呢？肯定是单一变量比较好。
　　仍以上例的按键来说明。假定按下X,Y,U,V,Z,A,B,C之一,对应执行不同的操作，那么：
　　switch（key）
　　{
　　case ＂X＂:
　　ProcessXAxisMove（）;
　　break;
　　case ＂Y＂:
　　ProcessYAxisMove（）;
　　break;
　　case ＂U＂:
　　ProcessUAxisMove（）;
　　break;
　　.......
　　}
　　这样看上去更清晰些。
　　当然，也有if/else与switch混合使用的情况，程序看上去会很繁杂。为了使程序大逻辑更清晰，一般都要适时地用子程序来简化。
　　结尾：一个优秀的程序员，都有一套严格的编程逻辑，善于把程序做的很有条理，少有bug。if/else能够把复杂的逻辑关系表达得清晰、易懂，包容了程序执行的各种情况。
　　只有if/else用的好、用的准确，才能实现可靠性、易操作性。
　　（图片来源于网络，仅用于辅助说明）
　　switch是回家玩的，if else是上班用的[看]
　　从C/ C++来看，当分支较多且switch要比较的值是连续的话，执行速度远远远远快于if，因为switch是直接跳到目标代码执行的，而if则需要执行很多条语句，慢的不是一点点，一般编译器会根据分支数量和比较的值是否连续生成不同汇编代码，如果编译器判定不能提升速度的话，switch生成的汇编代码和if是一模一样的没有任何区别。
　　至于很多人不用switch我觉得可能是:
　　1.为了方便写代码，思维习惯随手就用if写了;
　　2.可能根本就不懂为什么要用switch吧。
　　送大家以下java学习资料
　　我曾经接手过一份代码，遇到过一个三十几个if else套if else的模块。
　　心理骂骂咧咧谁他喵写的这玩意，然后开始review历史。
　　大致情况是这样的：第一个程序员写下这段代码时，只有两个if else；后来开始逐渐加需求，先是一个、两个，随后量变引起质变，于是逻辑分支快速扩张。
　　这个时候已经没有人愿意去重构成switch或是其他什么设计模式了，毕竟复杂度摆在那里，万一崩了还得背锅。
　　三四个程序员接手这段代码之后，就变成我现在这种局面了。
　　第一个程序员绝对没有料到这么简单的逻辑在之后会变成这么复杂的模块，甚至在增添第一第二条else时，也只是很随意的加上。
　　所以我觉得，这个锅绝对是是甲方的，让他娘的随便改需求。
　　这么一想心里就好受多了，编程嘛，最重要的是要看的开。
　　于是我又增加了两条else，测试，提交，下班。
　　有时候真的不是我们不想写好代码，是不能写好代码。写着写着需求砍了、需求变了，什么设计模式都不顶用，最终还是怎样快怎样方便怎样来，因为根本没人知道这段代码还能不能活的过下一段需求变动。
　　有的人肯定要说怎么不订合同。合同肯定是有的，但是明明白纸黑字写的合同，该改还是得改，毕竟你要是不同意甲方那些＂微小的变动＂，以后还做不做了？！金主真能去得罪？
　　还是要学会得过且过，跟什么过不去也不能跟自己过不去，糟糕的代码忍一忍就完了:代码能跑、头发不少，对我们这些打工的人而言比什么都重要。
　　现实工作绝不是课本中的理想状态，会有无数的突发情况在等着你。你定义了半天观察者、备忘录，第二天这部分需求被砍了；写了半天接口，抽象类，忽然下午告诉你要加个十万八千里打不着边的啥东西，于是又开始加适配器，等你加完了告诉你又砍了。甚至有次半夜被喊起来改代码，等改完了发现需求被撤回了，气的我直接请了两天假调整心情。
　　设计模式和大的框架绝对是一个项目中非常重要的东西，但不是绝对重要的；一个好的PM团队，在某种意义上，才真正决定了这个项目的代码质量。[1]
　　请用5秒钟的时间查看下面的代码是否存在bug。
　　OK，熟练的程序猿应该已经发现Bug所在了，在第8行和第10行下面我没有添加关键字break; 这就导致这段代码的行为逻辑与我的设计初衷不符了。
　　缺点一. 语法正确，逻辑错误
　　这就是第一个理由为什么程序猿很少使用switch来做条件判断，对于新手来说忘记写break实在是再普通不过了，就算是老猿忘记写也是时有发生的事情，而这个语法错误在诸多的语法检查器上没有办法检查出来的，因为从语法角度来说是正确的！可是代码的处理逻辑却是错误的！用if来重写这段代码的话，就不会发生这种错误。
　　上面的代码为了保证正确我添加了else做一个逻辑上的保证，其实如果不写else，这段代码也不会发生逻辑错误，而且一旦我忘记写花括号的时候，语法编译器是会提示我添加的，甚至可以使用eslint这种的工具强制我使用花括号，这样就不会犯语法错误了，一旦出现bug，那么肯定是我逻辑上的问题了。
　　缺点二 .死板的语法
　　switch尽管对于break很宽容，但是对判断条件很严苛，case后面只能跟常量，如果你用C编写的话，甚至只能用int类型作为判断条件。对于我们这么潇洒自如的程序猿来说，这种限制实在是太麻烦了，用if的话，别说是常量了，我用函数都可以，真正做到方便快捷。
　　缺点三 .需要子函数来处理分支
　　这个缺点跟缺点一有关，为了防止漏写break，因此建议把分支处理方法独立成一个子函数来处理，这样在阅读代码的时候就会减少忘记写break带来的bug，那么用if来写的话，我想怎么写就怎么写，非常随意自由，但是这也导致了代码的可读性大大降低。
　　switch的优点
　　既然switch有这么严重的缺点，那怎么在所有语言中依然会存在呢？那就说下switch的优点吧，它的优点也刚好是它的缺点。
　　在很久很久以前，那时候的电脑性能还不如一台小霸学习机的时候，聪明的计算机科学家为了提高计算机的处理速度，将一些逻辑分支处理方法简化了一下，把一些需要做逻辑判断的操作给固定死，然后只要查表一样一个一个对一下就能做出相应的反应了。
　　比如说a=0的判断，switch和if在cpu上面的处理方式是不一样的，switch是在编译阶段将子函数的地址和判断条件绑定了，只要直接将a的直接映射到子函数地址去执行就可以了，但是if处理起来就不一样了。
　　它首先要把a的值放到CPU的寄存器中，然后要把比较的值放到CPU的另一个寄存器中，然后做减法，然后根据计算结果跳转到子函数去执行，这样一来就要多出3步的操作了，如果逻辑判断多的话，那么将会比switch多处许多倍的操作，尽管寄存器操作的速度很快，但是对于当时的学习机来说，这点速度根本不够用啊。
　　那还有一个问题，为什么要使用break来做一个判断结束呢？这不是很容易造成语法错误了？那就要说到子函数的问题上了。
　　在早起的电脑代码中是没有子函数的概念的，那时候都是用goto随意跳转的，你想去第10行代码，很简单goto 10就可以了。这种编程思维在C的早期阶段还是一直受到影响的，因此早期的C也没有子函数，都是一堆逻辑处理混乱在一起，goto满天飞，所以那时候你没有一个最强大脑是写不了程序的。那为了告诉程序我这里条件判断处理结束，就添加了break作为终止符号。后来慢慢的有了子程序，有了更好的编程规范，才一步一步的将写代码沦落到体力劳动。
　　后来发展的新语言为了标榜自己的血统，多少都要参考下C，然后就把switch这种诡异的语法也继承下来了。但是也不是所有的语言都照搬，比如Google发明的新语言golang和kotlin就又把switch包装了一下，去掉了令人误会的语法，又让switch变得灵活起来了，对了，在代码重构的时候，还是用switch把，这样看起来的确代码更简洁哦！[2]
　　作为程序员来说，我更喜欢switch的结构，更直观更容易找到相应的代码块。不过为什么很多程序员不用Switch，而是使用大量的if...else if的结构，甚至像Python已经不支持原生Switch语法了？
　　这个原因很简单，因为switch语法结构最后编译还是通过if...else if来完成代码的，所以从效率角度来说和if...else if一样的。但是switch对比条件比较单一，绝大多数支持switch的编程语言都支持等于比较，也就是说变量只能等于case中的条件才会执行代码块。但是现实情况中，对比条件绝大多数比单一等于运算要复杂得多，因此很多程序员就直接使用if...else if。但是if...else if的结构，后期维护起来会比较不清晰，毕竟没有Case...Break那么直观。但是添加一些注解应该还是能解决这个问题的。
　　所以，我现在能使用Switch的时候还是会使用switch，毕竟后期代码维护起来方便点。不过更多时候还是用if...else if。
　　switch是给＂小枚举＂用的。所谓＂小＂就是基本类型的变量，很简单，但是很琐碎。
　　在Java中最新版本才允许复杂类型的switch。
　　实际工作中，逻辑要复杂的多。而且，许多情况复杂类型的equals的比较性能是低于notEquals的。
　　最后是流程灵活性。switch比较死板，注定没有if应用广泛。 使用防御型判断流程会更实用。
　　不是尽量别用，而是不合适没法用，合适得时候该用还是用。
　　比如说，变量i要求大于10，小于20,一条if(i>10&&i<20)就解决了问题，如果用switch，那岂不是自找麻烦。
　　又如变量i有5个固定返回值，10，20，30，40，50，那么用switch比较适合，用if也可以。
　　对于多变量判断，多重判断，复杂判断，还是靠if，switch几乎无能为力。
　　所以，switch多用在简单的枚举，对于很复杂的条件判断几乎无能无力，if则用在所有判断时候。简单的枚举又不很多，所以if最常见