BigDecimal保留两位小数失败问题

背景

测试时发现在线swagger测试会自动处理BigDecimal小数点后面的数字，就是有零的会都给你去掉，比如9.000与9.500到最后都会被swagger处理成9跟9.5。使用postman测是最准的，测出来的就是9.000跟9.500。

问题

处理运费计算结果时，setScale(2,BigDecimal.ROUND_HALF_UP)不生效

解决

BigDecimal的setScale方法会生成一个新的BigDecimal对象，生成时目前猜测是走了构造(猜测对了，看下图)，所以说BigDecimal在书写时一定要使用链式编程：
这么记：使用setScale方法后会new一个新的BigDecimal对象，这个时候就是两个对象了。新生成的对象你应该接收后再返回，这样才是setScale方法处理后的数据。

public class Test {
    public static void main(String[] args) {
        BigDecimal bigDecimal1 = new BigDecimal(5);
        bigDecimal1.setScale(2, BigDecimal.ROUND_HALF_UP);
        System.out.println("不用链式编程：" + bigDecimal1);
        System.out.println("使用链式编程：" + bigDecimal1.setScale(2, BigDecimal.ROUND_HALF_UP));
        BigDecimal bigDecimal2 = bigDecimal1.setScale(2, BigDecimal.ROUND_HALF_UP);
        System.out.println("用参数接，然后输出：" + bigDecimal2);

        BigDecimal bigDecimal3 = new BigDecimal(5.500);
        bigDecimal3.stripTrailingZeros();
        System.out.println("不用链式编程："+bigDecimal3);
        System.out.println("使用链式编程："+bigDecimal3.stripTrailingZeros());
    }
}

首先stripTrailingZeros()方法是一个去零方法，但是我们会发现这个返回的也是BigDecimal，但是不用链式编程却没有问题，这里面的原因是什么呢？原因其实很简单，很多人一想就明白了，肯定没有创建新的BigDecimal对象，而是使用静态的自定义常量（static final修饰的变量）或者是对BigDecimal对象做内部处理，感兴趣的可以点进去看看。

如何测试代码

测试的话最好用postman测，它相对于swagger来说是更严谨的。在运费计算接口中，实际返回的是9.000，但是swagger响应的就是9，这诚然不是我们想要的，我不需要你给我进行处理，因为这样我会造成误判。正好postman响应回来的就是9.000，所以选择使用postman。

使用postman时地址不要直接swagger上粘过去，打开F12，用swagger发一次请求，找到network找到请求头，然后复制访问的curl粘到postman