修复bug翻车记录

背景：

工作中接到一个bug排查修复任务，由于自己疏忽导致花了大量时间，记自己这次的翻车记录，大家引以为戒

直接上样例代码

    public ResponseUtil test(String titile) {
        List<ArticleDto> articleByTitle = articleService.findArticleByTitle(titile);
        List<ArticleDto> res = new ArrayList<>();
        状态默认都为0
        .........................中间省略一大堆业务逻辑代码
        for (ArticleDto articleDto : articleByTitle) {
            if(articleDto.getTotalNum() > articleDto.getOrderNum()) {
                articleDto.setStatus(2);
            } else if (articleDto.getTotalNum() == articleDto.getOrderNum() && articleDto.getOrderNum() > 0) {
                articleDto.setStatus(1);
            }
            res.add(articleDto);
        }
        return ResponseUtil.success(res);
    }

异常在于：

status0为不可用，1为已满，2为未满，按理来说订单数量大于0且和总量相等此时状态应为1，但返回的状态却是为0

翻车的过程：

实际工作中，其实这个bug涉及到很多方法和接口，由于该bug也不是我写的，是以前同事遗留的问题，我就开始了“漫长”的代码逻辑阅读，理清到一定程度后，就开始排查，代码逻辑我反复去论证，也尝试了自己觉得可能出现问题的好几种情况，但发现并没有问题，这就很头疼了，我以为是代码的逻辑出现了问题导致我一直反复去推敲业务的逻辑，做了许多的尝试，好了，也许是推敲太久或者其他原因，我觉得一段可疑的逻辑是有问题的，我就很自信的去改了，然后打包到开发环境去进行校验，结果好家伙，直接傻眼了，依旧是状态为0，这就很头疼了,到这其实时间已经花费了一天多了。
然后没办法，只能打日志然后打包打开发环境去日志里面抓，结果发现好家伙，大家应该也猜到了，他压根就没进去判断订单数量和总量相等的if里面，所以压根没运行到里面的逻辑，所以他当然返回初始状态0了，那很明显了，是那个==的问题，其实我当时看代码的时候，我也觉得这个好像怪怪的，但看他是Integer类型我就下意识觉得应该不是，只能说真的大意了，很容易的将Integer和int划了个等号，其实两个还是有很多区别的，这么个简单的bug我竟然花了两天，真的就翻车，虽然可能一方面是工作没多久经验不足，但更多的是自己的思维不会去转变，其实看见他都是0，就应该反应过来他没执行里面的逻辑，就很容易想到是没进判断里面，吃一堑长一智吧。

解决：

其实很简单，把==换成用equals去比较就好了

小知识：

包装类比较最好用equals，还能防一手bug
Integer和int不能划等号，两者还是很大区别的
int是基本数据类型，默认值为0，Integer是引用数据类型，是包装类，默认值为null。
==比较基本数据类型比较的是值，而比较引用数据类型的话比较的是内存地址，所以很容易出现包装类比较明明内容、值一样但比较结果为false，大家一定要引以为戒，引用数据类型还是建议使用equals进行比较。