起因
公司项目开发，遇到一个问题，保存手续费信息是发现，数据库中存在奇异数字10w， what ，支付5元手续费10w是要逆天？ 询问测试发现并没有改数据库。。代码问题？
查找问题
使用同样的报文，进行测试，发现无法触发该问题。。有毒。。（半个小时过去了）查阅了下上下文的调用，发现，出现问题的情况都是先调用了收银台支付，才发生这个情况。
测试了下，发现能触发。（重现问题）重现后，调用获取手续费，断点并打印，发现？？？ 传的是0.10？？对象没问题呀，保存前保存后，都没问题，但是，数据库存入的数据是10w？？找db抓数据，发现发送给数据库的数据是10w，这尼玛什么鬼。。。怀疑前面的计算手续费有问题，直接不实用计算的手续费了，new 了个 BigDecimal 0.1 保存，同样 10w。。搞事情。。。
不明所以
不知道该怎么办了，查看代码，既然都是手续费，那么。。网关也触发了手续费呢。。是否由于网关的手续费导致的呢，写死网关保存的手续费0.10，然后调用。发现，不触发了。。查看原先网关情况
原因
由于原先网关保存手续费中，手续费是空的，所以数据库里面存了个空进去。之后所以触发的保存，这个BigDecimal 字段 都是被 乘了10w。。
解决
将所以的 BigDecimal 这个对象，保存时，如果为空都设定Zero进去。。(后续尽量不要将BigDecimal 的null 被报错入数据库中，最好赋值Zero 报错，以防发生这个神奇数字的问题)
同上 10w 是哪里来的呢，我做了个测试发现是小数点后几位，就是10的几次方。 DECIMAL_DIGITS = 4 就 10的4次方 1w 如果 是6 就是 10的 6次方 100w了
其他
hibernate版本， 5.3.5 数据库 sybase