對于有界限的東西（數(shù)值，buffer空間，隊列或一切對象容器），一定要考慮越界判斷。
啟示：用snprint, strncpy等限制長度. 永遠(yuǎn)都要考慮超過邊界的情況
數(shù)值加法和乘法：考慮上限溢出;
減法：考慮負(fù)數(shù); 除法，判斷分母
2. 輸入?yún)?shù)非法
case1: 扣錢邏輯，減去一個負(fù)數(shù)，變成了加錢。
case2: int型大負(fù)數(shù)相加，負(fù)溢出變成大正數(shù)
啟示：test case要全覆蓋輸入?yún)?shù)范圍, 處理各種可能的情況
3. 上下文改變錯誤
共享變量/全局變量被外部改變，這似乎很常見，而且有時很隱蔽。在異步回調(diào)的情況下更常見。
check A變量
call func_B()
....
A變量被func_B改變了, 但繼續(xù)信任A變量check的結(jié)果。
啟示：白盒復(fù)查代碼時，注意檢查調(diào)用后的變化。
減少共享變量和全局變量的使用
外部接口調(diào)用后，注意共享變量的更新和恢復(fù)
啟示：在最接近執(zhí)行的地方，檢查上下文變量。不信任調(diào)用者，如果效率不關(guān)鍵，多一遍冗余檢查沒有壞處
4. 執(zhí)行中斷
動態(tài)腳本拋異常，或者引擎層面的EINTR中斷信號，都有可能中斷代碼執(zhí)行，需要考慮函數(shù)的重入性問題。
啟示：要檢查一致性，有些邏輯不允許多次被執(zhí)行（比如發(fā)獎勵），需要有狀態(tài)變量確保只執(zhí)行1次（避免出刷bug）
推廣到異步環(huán)境（多線程，多進(jìn)程，各種回調(diào)），事務(wù)的中斷也有一個重入性問題，解決方法也只有一個：用一個唯一可辨認(rèn)的狀態(tài)變量，保證某些邏輯不會被多次執(zhí)行（比如購物應(yīng)用中，用唯一訂單號來識別，狀態(tài)改變是一次性的，當(dāng)邏輯運行多次，也不會重復(fù)加物品，或者重復(fù)扣錢了）
5. 終止條件問題--死循環(huán)
case: 異步環(huán)境中，RPC遠(yuǎn)程調(diào)用，調(diào)用成環(huán)，邏輯一直不結(jié)束。
啟示：while或遞歸的終止條件，邏輯全覆蓋檢查，避免死循環(huán)。較深層次的互相調(diào)用，要注意是否出現(xiàn)了遞歸，是否有可能死循環(huán)。
6. 關(guān)聯(lián)數(shù)據(jù)操作的不一致
例子：Employee對象有company變量， Company中有employee變量，
如果操作改變其中一方，而另一方?jīng)]有改變，則造成數(shù)據(jù)不一致。
（數(shù)據(jù)庫表可以指定constrain, 關(guān)聯(lián)表刪除, 但代碼變量中需要程序員自己實現(xiàn)）
雙向引用的數(shù)據(jù)一致性問題，要特別注意。
為什么要雙向引用？為了查找效率，而避免遍歷其中一方.
這個問題本質(zhì)是數(shù)據(jù)一致性問題，編程中遇到的很多bug也歸結(jié)到這個問題，比如野指針，就是因為數(shù)據(jù)結(jié)構(gòu)相互引用的操作不一致造成的。
處理這個問題，個人經(jīng)驗是，他們的attach，detach操作盡可能在同一個模塊，不要分散在多個地方隨意修改，所有修改都集中在同一級接口做。
同理適用于new, delete, malloc, free這些分配，釋放，都集中在同一層的接口/模塊文件中做，debug起來也容易；非常反感在一個地方new, 然后不知道哪個模塊去delete, 很容易泄漏或者野指針, 無論如何，想辦法傳遞這些指針，一直傳到分配他所在的模塊文件中釋放，而且new和delete的接口代碼要靠近，方便查找問題。
7. 涉及多玩家，防止筆誤傳錯參數(shù)
經(jīng)典錯誤： foreach(uid in team) some_func(usernum, xxx)
經(jīng)典錯誤：有usernum和target兩個對象，調(diào)用函數(shù)搞混了。review時要仔細(xì)檢查
8. 特殊分支忘了return
異常判斷等if分支忘了return。導(dǎo)致邏輯繼續(xù)往下走。這屬于筆誤問題，測試期間未必能留意的到。
9. 異步返回沒清變量
對于異步操作，如果在返回時清變量，這時如果不能保證把變量清掉（比如期間玩家下線無法離線修改該變量），就會出刷。
啟示：對于已獎勵標(biāo)記，一定要保證各種情況下領(lǐng)獎后能正確記錄。
10. 瞬爆容量上限
case1: 網(wǎng)絡(luò)待發(fā)送隊列，因為瞬間大量請求，塞滿拋異常，導(dǎo)致流程受影響。
case2: 大量連接請求，listen的accept沒有規(guī)定單次讀事件的accept，用了while(true), 導(dǎo)致爆機(jī)
在listen fd的讀事件回調(diào)中, 通常會accept所有新的連接請求，如果用while(true)而不設(shè)一個上限，就有可能被攻擊（想象一下客戶端也用一個死循環(huán)來做connect)。
一方面要限制單次接受的socket次數(shù), 另外各個狀態(tài)要有超時機(jī)制，踢掉不尋常的連接，以防被攻擊占盡資源。
case3: 異步情況下，要限制操作者連續(xù)頻繁的操作。（比如在請求入口處增加最少時間間隔限制，避免玩家狂點，形成雪崩效應(yīng)）
（同時要考慮用戶體驗，不要讓玩家死等，可以做一個提示跳轉(zhuǎn)，或者等候的動畫）
參考資料：
附上最近看的一篇文章
<Writing-reliable-online-game-services> 作者曾是魔獸爭霸和星際爭霸，battle.net的開發(fā)者，
里面講的point也是游戲里經(jīng)常遇到的可靠性問題。
http://www.codeofhonor.com/blog/wp-content/uploads/2012/04/Patrick-Wyatt-Writing-reliable-online-game-services.pdf