? ? ? ?以前一直都是在編程中撬陵，用switch...case和if....else混合一起使用。但是我個(gè)人的習(xí)慣是如果可以网缝，我都會(huì)盡量使用switch語句進(jìn)行條件判斷巨税。這只能說是個(gè)人習(xí)慣吧，以前也一直沒有想很多粉臊，只是單純的覺得比起if語句垢夹，使用switch可以簡化我的輸入，而且后面我在審視自己的代碼的時(shí)候也會(huì)覺得比較容易讀懂维费。
? ? ? ?最近小學(xué)期上課的時(shí)候果元，是一位公司的老師給我們上課，我觀察了一下他的代碼習(xí)慣犀盟，他傾向比較多的條件判斷的時(shí)候而晒，就使用switch，但是在小范圍的條件判斷中阅畴，他比較喜歡用if倡怎，我覺得這其中應(yīng)該是有一定道理的，突然想起之前我在看《高性能javascript》的時(shí)候贱枣，作者也提出了這方面的優(yōu)化监署。特此重新回顧了一下之前的書里的內(nèi)容，結(jié)合網(wǎng)上大牛們的解釋纽哥，做一次歸納總結(jié)吧钠乏。
使用if-else還是switch，最流行的方法是基于測試條件的數(shù)量來判斷：條件數(shù)量越大春塌，越傾向于使用switch而不是if-else晓避。這通常歸結(jié)于代碼的易讀性。這個(gè)觀點(diǎn)認(rèn)為只壳，當(dāng)條件較少時(shí)俏拱，if-else更易讀，當(dāng)條件較多時(shí)吼句，使用switch更加易讀锅必。--《高性能javascript》
之后，我在維基百科也搜了一下switch_statement的有關(guān)資料惕艳，關(guān)于它的Compilation搞隐，維基百科作出了如下的解釋：
也就是說驹愚，在編譯器中，它會(huì)將一系列的語句編譯成分支表尔许，然后在判斷時(shí)么鹤，無需像if-else語句一樣一個(gè)個(gè)進(jìn)行邏輯判斷，而是通過在case里的值味廊，對值進(jìn)行搜索蒸甜，從而達(dá)到對搜索的優(yōu)化。我也在知乎搜索了一下余佛，但是發(fā)現(xiàn)不知道是不是我打開方式有問題柠新，關(guān)于這方面的解釋比較少，或者說辉巡。恨憎。問題太簡單了。郊楣。憔恳。然后我找到了如下作者的回答（如果涉及侵權(quán)請聯(lián)系我，我將立刻刪除净蚤，謝謝钥组。）
switch通過編譯成一個(gè)分支表來達(dá)到優(yōu)化的目的，我個(gè)人感覺是通過空間的代價(jià)來換取時(shí)間今瀑。說完了switch...case程梦，現(xiàn)在我們再來對比一下if-else，沒有對比就沒有傷害橘荠。它和switch不同屿附，if-else語句會(huì)對一個(gè)個(gè)條件按順序進(jìn)行查找，直到找到符合條件的"入口"哥童。也因?yàn)檫@個(gè)特性挺份，所以，當(dāng)條件數(shù)量很大如蚜，它和switch的差距就慢慢顯現(xiàn)出來了压恒。
事實(shí)證明，大多數(shù)情況下switch比if-else允許得要快错邦，但只有當(dāng)數(shù)量條件很大時(shí)，才快得明顯型宙。當(dāng)條件增加的時(shí)候撬呢，if-else性能負(fù)擔(dān)增加的程度比switch明顯得多。因此我們傾向于在條件數(shù)量比較少的情況下使用if-else妆兑，而在條件數(shù)量較大的時(shí)候使用switch魂拦，出于性能考慮毛仪，這是合理的。--《高性能javascript》
我個(gè)人的使用習(xí)慣是芯勘，當(dāng)只有涉及到true||false的時(shí)候箱靴，我才會(huì)傾向于使用if-else語句，如果涉及到常數(shù)荷愕，或者數(shù)值的判斷衡怀，我一般傾向于使用switch，事實(shí)證明安疗，這種做法也是對的抛杨，出于對代碼的可讀性也好，出于性能考慮來說荐类，我覺得我的使用習(xí)慣好像是正確的怖现。
但是這本書中，有提及對if-else的優(yōu)化：
最小化到達(dá)正確分之前所需要判斷的條件數(shù)量玉罐，最簡單的方式是將最可能的出現(xiàn)的條件放在首位........if-else語句應(yīng)該總是按照最大概率到最小概率的順序排序屈嗤，或者，最小化條件判斷的次數(shù)吊输，使用嵌套的方式等饶号。
但是我個(gè)人傾向于，代碼的易讀性璧亚，如果一味地使用嵌套讨韭，其實(shí)只會(huì)影響代碼的可讀性。
查找表【補(bǔ)充方案】
其實(shí)有時(shí)候優(yōu)化條件語句的最佳方案是避免使用if-else和我switch癣蟋，當(dāng)有大量的離散數(shù)值時(shí)透硝，查找表的優(yōu)勢就會(huì)慢慢體現(xiàn)出來，查找表這整個(gè)過程就變成了數(shù)據(jù)查詢或者對象成員的查詢了疯搅。
當(dāng)單個(gè)key和value之間存在有邏輯映射關(guān)系是濒生，查找表的優(yōu)勢就會(huì)體現(xiàn)出來。一個(gè)查找表可以看做是一個(gè)數(shù)組或者一個(gè)對象幔欧，通過索引操作來取代邏輯運(yùn)算罪治，由于這樣子的映射關(guān)系，可以讓運(yùn)行效率提高礁蔗。
查找表最主要的優(yōu)點(diǎn)是觉义，不用任何條件判斷語句，即使候選值增加浴井，也不會(huì)有額外的性能開銷晒骇。switch語句比較適合每個(gè)key都需要有獨(dú)特對應(yīng)一個(gè)或者一系列的動(dòng)作的時(shí)候。
關(guān)于switch...case && if...else效率比較和優(yōu)化就到這里了，一切共勉洪囤。本文仍存在很多不足徒坡，希望各位加以指點(diǎn)~謝謝。
# 補(bǔ)充于 2018-05-09
拋開我們所說的內(nèi)存也好瘤缩，效率也好喇完，如果讓我來總結(jié)這兩個(gè)判斷的一個(gè)異同點(diǎn)，我更傾向于用使用場景和你解釋剥啤，我們更傾向于用 if 去判斷連續(xù)的區(qū)間 用 switch 去判斷離散分布的可能取值锦溪，也就是說：
if 比較適用的場景是 目標(biāo)點(diǎn) 落在某一個(gè)區(qū)間 例如 90 < x <100 之類的
switch 比較適用的場景是 x = blue? .... x = red ..... 之類的處理場景
推薦閱讀：
