汽車防御性駕駛是一種安全駕駛的理念和實(shí)踐，旨在最大程度地減少交通事故的發(fā)生，并保護(hù)駕駛員、乘客和其他道路使用者的安全。防御性駕駛核心在于合理懷疑其他交通參與者可能會(huì)做出危及安全的行為并提前做出預(yù)判，比如碰到路口預(yù)判前面可能沖出來(lái)小孩。碰到前面緩慢，預(yù)料到自己急剎可能導(dǎo)致跟得很近的后車追尾上來(lái)。

在編程領(lǐng)域也有防御性編碼（Defensive coding），有著與汽車防御性駕駛相似的理念，它也是保護(hù)我們的系統(tǒng)的一種實(shí)踐，減少線上事故的發(fā)生。

一個(gè)大型系統(tǒng)必然是多個(gè)團(tuán)隊(duì)的協(xié)作成果，團(tuán)隊(duì)之間的接口調(diào)用通常靠文檔規(guī)范約定，這些接口文檔也便形成了一份份規(guī)約。可能有人會(huì)說(shuō)對(duì)方團(tuán)隊(duì)不遵守文檔規(guī)范是對(duì)方的問(wèn)題，不關(guān)我們團(tuán)隊(duì)的事情啊。對(duì)于這個(gè)問(wèn)題，我只想說(shuō)只關(guān)心自己不被追責(zé)而不關(guān)心技術(shù)全局是否完善的技術(shù)人員注定發(fā)展空間是有限的。因?yàn)楦黝愐?guī)范只能保證下限，在團(tuán)隊(duì)與團(tuán)隊(duì)的協(xié)作中僅僅按契約完成規(guī)范還不夠，就像僅按交規(guī)開(kāi)車并不能防止事故一樣，我們還需要防御性編碼的意識(shí)與實(shí)踐。那怎樣做到防御性編碼呢？下面是最常見(jiàn)的一些手段：

1、日志記錄

作為本系統(tǒng)與外部系統(tǒng)接口交互的記錄，必須要記錄日志。日志無(wú)論在事中查錯(cuò)、事后追責(zé)提供證據(jù)方面都有著不可替代的作用。如果自己的系統(tǒng)沒(méi)有日志，就只能寄希望于上游或下游記錄了日志，這有時(shí)不僅受制于人，還可能會(huì)為日后互相甩鍋埋下隱患。對(duì)于重要的（如涉及資金），或者頻繁需要查日志的系統(tǒng)間交互，不僅需要打印應(yīng)用日志，還需要考慮將這些日志記錄到數(shù)據(jù)庫(kù)或NoSQL中并提供方便的查詢界面以提高查詢的效率。

2、協(xié)議之外

比如某第三方支付系統(tǒng)的接口規(guī)定，調(diào)用支付接口后返回報(bào)文的支付狀態(tài)字段，1代表支付成功，0代表支付失敗，-1代表不確定。結(jié)果線上因?yàn)閷?duì)方升級(jí)協(xié)議的原因，多了一個(gè)狀態(tài)2，而這個(gè)業(yè)務(wù)的程序員又沒(méi)足夠的經(jīng)驗(yàn)預(yù)判這種情況，引起了大面積的支付錯(cuò)誤投訴。他的代碼是這樣寫(xiě)的：

if(status == -1){
    //支付結(jié)果不確定處理
}else if(status == 1){
    //支付結(jié)果成功處理
}else{
    //支付結(jié)果失敗處理
}

可以看到他把新出現(xiàn)的這個(gè)狀態(tài)當(dāng)成支付失敗處理了。對(duì)于這種出現(xiàn)了協(xié)議之外的值的情況，在業(yè)務(wù)開(kāi)始可以拒絕的情況下直接拒絕該請(qǐng)求調(diào)用。在不能拒絕的情況下（如本例中用戶已經(jīng)輸入支付密碼完成支付，不能再拒絕請(qǐng)求調(diào)用了）則需要在業(yè)務(wù)上兼容處理，比如這里可以把這種情況視為支付結(jié)果不確定，最后再根據(jù)對(duì)賬取得最終的支付結(jié)果是成功還是失敗。

3、輸入限制

常見(jiàn)的輸入類型有整數(shù)、小數(shù)、字符串等，我們必須檢查輸入字段是否符合接口文檔規(guī)定的類型，并限制字段的基本長(zhǎng)度。同時(shí)也從業(yè)務(wù)角度去檢查字符串是否滿足格式，如常見(jiàn)的身份證、郵箱、手機(jī)號(hào)碼等是否滿足各自規(guī)定的業(yè)務(wù)格式。

4、輸入過(guò)濾

比如你提供了一個(gè)搜索接口，但你不確定上游會(huì)輸入一句話還是一篇文章，光靠雙方自覺(jué)地按接口文檔去約束顯得既蒼白又無(wú)力，一刀切停止服務(wù)似乎又過(guò)于簡(jiǎn)單粗暴。一個(gè)可行的方法是無(wú)論上游輸入多少，只截取前30個(gè)字符去ElasticSearch中查詢（接口協(xié)議文檔中明確約定）。有時(shí)候?yàn)榱俗约合到y(tǒng)的安全，對(duì)于明顯超出正常業(yè)務(wù)范圍的字符也會(huì)進(jìn)行過(guò)濾，如常見(jiàn)的<>&\r\n等。

5、邊界判斷

一個(gè)常見(jiàn)的問(wèn)題是只檢查了下限沒(méi)檢查上限，比如商品數(shù)量數(shù)據(jù)，通常會(huì)做大于0檢查，但卻很少會(huì)去檢查上限。比如在Java中當(dāng)我們使用內(nèi)置運(yùn)算符做數(shù)學(xué)運(yùn)算時(shí)，如果結(jié)果超出變量類型表達(dá)范圍，結(jié)果會(huì)并不會(huì)拋出異常，而計(jì)算結(jié)果又是不符合預(yù)期的。如兩個(gè)大的正整數(shù)相乘，結(jié)果可能溢出后變成了負(fù)的。這就要求我們對(duì)字段的數(shù)值范圍，業(yè)務(wù)取值范圍進(jìn)行進(jìn)行邊界判斷。

6、接口限流

我們知道，系統(tǒng)之間交互模式有推送與拉取。拉取雖在及時(shí)性上不如推送，但它可以根據(jù)系統(tǒng)自身的能力量力而為地處理業(yè)務(wù)，能較好的保護(hù)自身。而推送則有可能出現(xiàn)能力不匹配的情況，如果上游推送很快，自己的系統(tǒng)又處理不過(guò)來(lái)則需要提前做好限流，并確保上游能兼容限流的情況。

7、重復(fù)請(qǐng)求處理

如果指望通過(guò)一紙規(guī)定就能避免調(diào)用方重復(fù)發(fā)起，就能避免被調(diào)用方重復(fù)處理問(wèn)題，那就未免顯得有點(diǎn)天真了。因?yàn)橹貜?fù)可能發(fā)生在應(yīng)用層，也可能發(fā)生在框架或其它層，未必就是調(diào)用方主觀的行為。對(duì)重復(fù)請(qǐng)求的處理，有些情況可以用冪等處理，除了部分業(yè)務(wù)本身就是冪等的，其他多數(shù)是通過(guò)業(yè)務(wù)惟一索引進(jìn)行限制實(shí)現(xiàn)。需要指出的是有些系統(tǒng)是通過(guò)先查詢數(shù)據(jù)庫(kù)或緩存再判斷是否是重復(fù)請(qǐng)求的還需要注意原子操作問(wèn)題。

8、金額單位

要特別小心涉及金額的接口處理。對(duì)金額的處理，不同的系統(tǒng)有不同的標(biāo)準(zhǔn)，同樣對(duì)于1.23元，某互聯(lián)網(wǎng)公司的支付系統(tǒng)規(guī)定以分為單位的整數(shù)（如123）；某電信系統(tǒng)則規(guī)定以厘為單位的整數(shù)（如1230）；某金融系統(tǒng)又規(guī)定是以元為單位的字符串（如1.23）。尤其需要小心對(duì)最后一種情況的數(shù)值范圍判斷，涉及到字符串轉(zhuǎn)數(shù)字，要小心精度丟失。在Java中涉及小數(shù)的計(jì)算，多數(shù)情況使用BigDecimal。

防御性編碼要求我們跳出責(zé)任歸屬的視角系統(tǒng)性地看待全局問(wèn)題，對(duì)可能發(fā)生問(wèn)題的地方提前預(yù)防，對(duì)事故高發(fā)情況提前預(yù)判，保護(hù)自己系統(tǒng)的同時(shí)也保護(hù)上下游系統(tǒng)，取得全局最優(yōu)解而不僅僅是局部最優(yōu)解。