自以爲開發經驗多了犯低級錯誤的概率會減少，被同樣的問題一次次打臉後我深刻認識到我太高估自己了，以爲自己的大腦足夠用，能自帶免疫功能；其實一直都知道減少犯同樣錯誤的唯一方法就是不斷的積累和總結，偷懶真的會摔跟頭，自己挖的坑還是要自己填。
於是我的錯誤總結由此開始。。。。
從哪個bug寫起呢？如果要把我開發至今的bug都列出來，估計要寫一本書吧
，這就是一段不堪回首的血淚史啊啊啊啊啊。
經過一番挑選之後我決定記錄下一些比較容易忽略和經常出現的bug。
一，反射型xss漏洞
正如下圖所示，傳入參數是字符串類型這種情況；如果有對參數進行輸出，記得要把參數轉義後再輸出，或者輸出不帶參數
如何轉義呢，以下面爲例
1. jsp頁面，將輸入的字符串參數轉碼：
2. addProduct.jsp接口，將轉碼的字符串解碼後輸出：
二，傳異常值報錯
慣性地用正常值進行測試往往忽略了異常值的結果，以下兩種情況都是沒有對傳入參數的數值範圍進行充分測試。
1.
2.
針對第二種pageNo傳入超大頁碼的情況，可以先判斷是否超過當前最大頁碼，超過時直接返回空數據不再進行查詢。
Pager<Account> totalAccountPager = accountService.getSuccessApplyAccount(1, 1, trialID, accountId);
int total = 0;
if(totalAccountPager != null){
total = totalAccountPager.getTotal();//總數據量
}
int count = total > pageSize ? (total/pageSize + total%pageSize) : 1;//總頁數
Pager<Account> accountPager = null;
if(total > 0 && pageNo <= count){ //在頁數範圍內才進行查詢
accountPager = accountService.getSuccessApplyAccount(pageNo, pageSize, trialID, accountId);
} 三，性能超標
性能超標不外乎三種原因：sql效率低，需求規則複雜和代碼邏輯問題。首先是解決sql和代碼邏輯問題，如果還是超標才考慮需求規則是否可以更改。如果以上三個優化後還是超標就看超標率是否在接受範圍內了。
四，代碼邏輯不嚴謹（這個不知道怎麼定義，先這麼叫吧）
1.
.
當集合idList爲空時調用addAll方法會報空指針，因此我先判斷idList非空時再調用addAll方法；不會報錯了，但問題來了，我忽略了其爲空的情況；因爲下面有個排除的規則，如果idList爲空，但ids集合不爲空，ids不會被加入idList集合中，排除步驟裏不會將ids排除掉，所以考慮爲空的情況做了以下修改：
2
這裏只判斷了產品是否存在，但忽略了是否是審覈通過的產品，所以判斷對象需要全面
五,瀏覽器的兼容性
對瀏覽器的兼容性主要是頁面的樣式兼容，一般的瀏覽器包括chrome 火狐 360 搜狗 IE；需要在不同瀏覽器上測試頁面是否正常顯示
六，輸入的字段長度與實際數據庫保存的長度要匹配
數據庫中無論是中文還是英文都佔一個字符的長度，代碼若根據編碼判斷兩個英文相當於一箇中文的長度，此時如果允許輸入的最大長度和數據庫的長度一樣，當輸入最大長度時頁面判斷會通過但數據庫會由於超過字段長度報錯
解決方案：保持前端頁面和數據庫判斷的一致性，頁面不根據編碼來判斷，將中文和英文的長度都看作一樣；或者修改數據庫字段的長度，但這個不太可取，因爲起碼要將長度加大一倍才能滿足要求。