RestAssured中匹配BigDecimal类型1.0应使用哪种Hamcrest匹配器？

这个问题我之前也踩过坑！核心原因是Hamcrest的is()匹配器会做严格的类型检查：你断言里写的1.0是Double类型，但因为DTO里的字段是BigDecimal，RestAssured解析JSON后得到的实际值是BigDecimal类型。虽然数值显示都是1.0，但Java中不同数值类型的equals()判断会返回false，所以才抛出了这个看似矛盾的断言错误。

下面给你几种靠谱的解决方案：

方案1：用BigDecimal实例作为期望值 #

直接构造与DTO类型一致的BigDecimal对象作为断言的期望值，这样类型和数值都能精准匹配：

.body("entity.value", is(new BigDecimal("1.0")));

或者用BigDecimal.valueOf()来构造，效果完全相同：

.body("entity.value", equalTo(BigDecimal.valueOf(1.0)));

（注：is()其实是equalTo()的语法糖，两者功能没有区别）

方案2：用BigDecimal专属的数值比较匹配器 #

如果担心精度问题，或者想更明确地处理BigDecimal的数值比较，可以用Hamcrest提供的comparesEqualTo()匹配器——它会调用BigDecimal的compareTo()方法，只判断数值是否相等，不严格要求对象完全一致：

import static org.hamcrest.Matchers.comparesEqualTo;

.body("entity.value", comparesEqualTo(new BigDecimal("1.0")));

方案3：指定提取值的类型（不推荐，仅作补充） #

你也可以在断言时明确指定JSON路径值的转换类型，让RestAssured自动把提取到的值转为Double，再和你的期望值比较：

.body("entity.value", is(1.0), Double.class);

不过这种方式不够严谨，如果DTO的BigDecimal有更高精度的数值，转换为Double可能会丢失精度，所以更推荐前两种方案。

内容的提问来源于stack exchange，提问作者alekz