阿里巴巴 Java 开发规范:货币金额，均以最小货币单位且整型类型来进行存储, 和前端的交互也用整形吗?

[gancl]

和前端的交互也用整形吗? 我们现在内部是给前端用元, 存数据库用分单位.

如果忘记转换, 差的就是 100 倍的价格, 用 BigDecimal 差的就是 1 分钱的价格, 两个相比较起来, 还不如用 BigDecimal

在微服务内部互相调用, 返回的价格应该和给前端的是一样的, 会转了又转

想问下这个规则要怎么使用?

[EarthChild]

阿里巴巴又不是王法，问你客户去。

[gancl]

@EarthChild 有好的就用,如果不好就不用. 所以想问下哪种做法比较好

[liprais]

不用 decimal 就是给自己找不愉快

[wolfie]

不是有测试环节吗。

[keshawnvan]

注意描述：“来进行存储”

[lagoon]

想起之前某次面试，问到类似货币处理的问题，我答使用整型储存，面试官表示这有问题。

我问我们这么做，但暂未发现有什么问题，能请教一下会有什么问题吗？

对方表示反正就是有问题。

我觉得用整型挺好，这种规范还可以全面统一。用 BigDecimal ？全世界只有一种语言：Java ！非 Java 不是编程语言！

[NULL2020]

时刻提醒自己要转换就行了。

我司也是这样做（我说了算），数据库存分，代码里转成（元）字符串的格式，前端传过来也是字符串（元）

[BBCCBB]

整形性能高啊.

[AoEiuV020]

为什么会把“如果忘记转换”纳入考量，这种必须消灭的 bug 来决定设计不奇怪吗，
钱的东西一分都不能差，整数比较容易控制每一分钱，毕竟拆开再合起来是严格相等的，
前端的话我觉得最好是返回一样的整数让前端自己转换，除非是纯展示，就直接转换返回需要展示的字符串，

[jackmod]

整数也好，不过最小货币单位不一定是分

[gancl]

obj.setRechargePrice(AmountConversionUtil.strCentToYuan(obj.getRechargePrice()));
obj.setComplimentaryPrice(AmountConversionUtil.strCentToYuan(obj.getComplimentaryPrice()));
obj.setRechargeSurplusPrice(AmountConversionUtil.strCentToYuan(obj.getRechargeSurplusPrice()));
obj.setComplimentarySurplusPrice(AmountConversionUtil.strCentToYuan(obj.getComplimentarySurplusPrice()));
请问下这种怎么用一个类似这种写法:
LambdaQueryWrapper<Dict> lqw = Wrappers.<Dict>query().lambda()
.eq(Dict::getCode, dict.getCode())
来写?一不小心就左右两边写错方法了
@NULL2020

[zzzmode]

然而支付宝自己开放平台下单接口金额好像就是元为单位的😂

[gancl]

还有个问题, entity 是 int 类型, vo 是 string 类型, BeanUtil.copy 时是复制不过来的,这个要怎么注意? @AoEiuV020 @NULL2020

[siweipancc]

@gancl hutool 包应该可以隐性 cast

[l00t]

和前端交互用字符串，还能带个货币单位出来。

[Jooooooooo]

大家都用整型方便.

[NULL2020]

BeanUtil.copy 时是复制不过来的
--- 手动赋值啰，都手动转换了，还差这点功夫吗？

[shellus]

用整数分为单位没有解决任何问题，反而增加了一些问题
1：一个系统原本设计商品的价格单位为 0.00 精度，但是后期需求改为 0.0000
2：给代码各处的储存获取，传递处增加很多无谓的复杂性，创造了更多犯错的机会

[gam2046]

用最小计量单位作为整型存储，可以避免一些不可预期的精度丢失，尤其是需要对账的时候。

例如订单金额 100，用户使用优惠券 12.34 ，实付 87.66 ，后期发生部分退款 20，实际需要退款的金额大约为 17.532 ，以分存储即最多损失 1 分，而 BigDecimal 仅存在于 Java，跨语言时，通常还需要转换，最后可能还是转换成了以分为单位。

[pengtdyd]

我怎么记得 java 开发开发手册里面是说：涉及到金额的要用 Decimal 或者整数和小数分开存储