描述一下背景：

    8月上線了個新專案，是對老系統的全量翻寫，老系統之前大多數使用者用的IE8瀏覽器（金融行業的很多操作電腦都是xp系統及IE8瀏覽器）。新系統採用springboot+hibernate+bootstrap組合開發，專案部署在WebSphere平臺。11月初遇到了一個非常重大且很隱蔽難以查詢的問題，這裡進行一下記錄，漲漲經驗，同時，也希望能給讀到的朋友有些幫助。

具體問題原因：BootStrapTable這個元件，對IE8瀏覽器的支援上存在了一個的bug所導致

1，問題表象:

    11.01號使用者大量錄入資料及修改資料，當天未能遇到任何問題，按照當時部分使用者反映的時間，截至當天晚上7點多，資料仍然是對的且校驗OK，甚至部分資料已經複核提交。第二天早上，問題發現了，大批使用者反映資料丟失，且只丟失了某一種型別資料，包括已提交的資料及未錄入的資料。在生產環境上進行資料排查中發現，某張表的所有的存量和增量資料某種型別全部丟失，其他有四張表資料也有少量的增量和存量的同種型別資料丟失。

排查過程：

    a，首先想到的是查系統輸出的當天11.01到11.02的日誌，查詢對某張表的刪除處理sql，但hibernate的sql輸出，對於引數是不可見的，都是問號？，所以，在分析了這兩天的日誌後，沒有看到有任何會去操作存量資料的可能性，僅有的三次批量刪除操作，均傳入了唯一主鍵code碼及多個控制條件，不可能刪除其他存量資料。

    b，第二個去查的是was日誌，或許was上會更詳細的記錄，但是和系統輸出的log檔案一樣，未能斬獲線索

    c，在排查的過程中，日誌資訊裡，符合操作時間的有一條delete操作，當晚8：16刪除的一條操作資料，所以立刻聯絡了操作員，操作員表示當時批量刪除了4條資料。日誌裡的delete操作，傳入了5個問號？，這裡就覺得有些不對了。

    d，應該感謝當初專案經理給系統多加了個詳細的引數傳遞日誌，得以對應到時間，查到那條刪除操作，除正常的4個code碼以外，竟然多傳入了一個空字串！！！

然後發現了。。。

資料庫中表是多表關聯操作，假如刪除某一條主表資料，其餘的表的資料會被刪除，但一般刪除時，傳入了唯一標識id，所以只會刪除一條資料，其他的表也刪除相關的資料而已，不會影響其他的資料。

這次錯誤的情況是，傳入了的空字串，恰好對應了其他表中某種資料型別，所以，導致該種資料型別的資料其他表資料被清空。。。

至於前端被傳入的空字串從何而來。。。為什麼應該傳入4個，但是傳了5個引數，多加了一個空字串的原因：

$("#id").bootstrapTable('getSelections');
 

這句程式碼在IE8裡的操作導致的。。。

具體bug：

    表格每行有一個checkbox，標題行提供了一個全選的checkbox，當第一頁資料假如有5條，你點選了全選，然後進行刪除操作，傳入後臺的每行的主鍵id，不是5個，而是6個，甚至是7個！！！在你原有的5個id後加入了兩個值為空字串的引數！！！

解決方法：有很多種，比如js空字串限制，後臺引數過濾都可以解決

   總結：

    1，我們用的是客戶提供的框架開發，不能把一切都相信別人的框架，要留一手自己的程式碼追蹤軌跡，如日誌等，hibernate的sql輸出只有？，也是應該要注意的，最好自己新增引數的傳遞，否則像這次情況，如果沒有引數記錄，估計就是永遠查不出來了

    2，中間還涉及很多次後臺DS抽數及job跑批的排查，我文中沒有描述，就不提了，最終發現不是這方面問題

    3，得虧我們有生產資料的多次全量備份檔案（資料庫為DB2，沒有回滾操作），所以11.2恢復了備份的資料，保證了存量資料，但是不可避免地丟失了部分的11.01增量資料（在刪除操作發生時，一部分空字串的資料型別資料就被匹配刪除了，這部分資料無法挽回），這也是值得警醒的，一定要進行定時備份工作