这bug你解决不了?

bug产生时间:15:46

背景：当一个用户有多个订单线路时,第N个订单取第N个线路的明细打印,那么会出现三种情况：

订单数量大于线路数量

订单数量小于线路数量

订单数量等于线路数量。

代码如下:

        int i = 2
        EntityWrapper<xxx> wrapper = new EntityWrapper<>();
        wrapper.orderBy("depart_time,create_time");
        List<xxx> list = Mapper.selectList(wrapper);
        if (CollectionUtils.isNotEmpty(list)) {
            if (i <= list.size()) {
                xxx = list.get(i - 1);
            } else {
                xxx = list.get(list.size() - 1);
            }
        }

排查过程：

1. 确认该用户的订单为第2单，那么应该返回第二条线路的明细，但是日志返回多次都不是第二条线路的明细。
2. 数据库确认，因为此逻辑多次测试后稳定上线20天了，查看数据库结果，确认第二条线路有客户C，但是返回的并不是C，查询日志，确实添加了客户C，且有详情日志
3. 再次确认代码逻辑，当订单数量为2时，list返回应该为3，那么取list索引为2的数据，则为该list的第三条数据，逻辑正常。
4. 再次查询日志，确认打印时刻客户C是否在线路3里，确认在…
5. 再次查询日志，确认打印时刻是否满足查询条件，满足…
6. 再次确认是否是第二单订单，确认…
7. 确认日期是否正确，确认正确…
8. 我他妈心态崩了…
9. 还得接着查，逻辑是否正确，正确…
10. 再次确认是否打印时刻数据是否正确，打印时，第一条线路与第二条线路的两个字段值一样，此时排序按入库顺序展示，则第二条客户明细不是C，为什么跟结果不一致？因为在打印的时候是9:18,在9:50对此线路进行了修改,将该线路的depart_time修改为大于第一条线路的时间，那么理论查询的是第二条线路，返回C，但实际返回的不是C是正确的，修改时间为9:54,bug确认解决，逻辑正确，时间为18:33。

也就是说用户在第一时间打印的数据不是数据库的数据，按着自己想像的数据进行打印，并在一段时间后修改为自己想要的数据，这里存在逻辑缺失，或者提示不明确，后期进行评审处理，但排查过程颇为辛苦，因为逻辑都正确的情况去排查不正确，本身就非常疑惑。至此bug顺利排查完毕。