BootstrapTable组件($("#id").bootstrapTable('getSelections');)在IE8浏览器上全选后，多出空字符串bug引发的重大问题及解决过程

描述一下背景：

    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增量数据（在删除操作发生时，一部分空字符串的数据类型数据就被匹配删除了，这部分数据无法挽回），这也是值得警醒的，一定要进行定时备份工作