准备开发和钱有关的功能，还有哪些地方要注意

如果预期后面金额会很大的话，字段类型是不是要用 long 型？而不是 int

看到 [t/569119?p=1#r_7407244]( t/569119?p=1#r_7407244) 有人说存成分，遇到利率汇率会有问题？

用 int 不可取，有些时候要用小数的，比如 10 元 9 个需要求单价。
我接触过的话几次金额相关的都用了 4 小数位或者 6 小数位 decimal

楼上说得对，之前做银行项目，要保留 6 位小数，所以一般都用 decimal，我是用 decimal(20,6) ，decimal(16,2)

- 用 decimal 避免精度问题；
- 用 ROUND_HALF_EVEN 来做处理，可搜下 银行家舍入法；
- 涉及汇率要谨慎，设置好警报，如果哪天接口异常，可及早处理（或者设置好默认范围，正常的波对不会很大）；
- 涉及提现要注意舍入问题，避免造成金额损失；

最该注意的难道不是安全么？

四舍六入五成双了解一下

@opengps #3
@lvsshuttao #4
@freakxx #5
可以，那就改用 decimal

int，存储的时候数字先乘 1000

后端要校验，我见过好多次前端改包修改订单参数，比如其中一个参数修改为负数，最终一元支付订单的漏洞。

Java 用 Money API，https://javamoney.github.io/

使用 BigDecimal，设置好 MathContext 和 RoundingMode。

所有跟钱相关的操作一定要留底，所有数据一定要能够溯源

后端用 BC math 就可以不用 int 了，用了 int 后端也就可以不用 BC 了，纯 int 技术不会出错。

严格意义上数据库的 decimal 能够满足需求但是数据处理上比较蛋疼，有条件的话用 bigint 存储分，然后整个后端操作里全都使用分单位,尽量避免小数的出现，唯一的缺陷就是 bigint 比较耗费空间 decimal 在 8 位小数时才用 8 个字节，考虑到分单位可能实际中只需要用 5 个字节，相当于每一条记录多浪费 3 个字节的空间，再加上金额这个字段有很多种，结合下来整体的开销还是不小的。所以这就是个用存储换舒适度的问题。

bc 函数传入参数用 string, 不然要报错
```shell
php > echo bcdiv(0,0.000001,8);
PHP Warning: bcdiv(): Division by zero in php shell code on line 1

Warning: bcdiv(): Division by zero in php shell code on line 1
```

你的系统不知道怎么样 ，两个方案你选吧
1. 使用 bigint,固定小数点位置，比如后三位是小数点
2. 使用 decimal
你在这里问，说明你这系统也没多大，所以哪种都行

宁愿少给 也不要多给

实际舍入模式要根据实际业务来，不能一味地用银行家模式，这样对账时才能理得清。不知道你是做终端用户的还是只是通道转接或者其他，不管哪方面注意筛选风险交易，也就是做好风控，类似的方面还有很多，有些重要地方特别要注意，一不小心就进去了。

找个专门做这个的律师咨询一下，这种进去了一版不是轻罪

1.涉及汇率，可能出现小数，例如中东项目一般要保留到 7 位小数。
2.事务回滚，一定要严测事务一致性。
3.操作日志，任何一步都要有日志（写入数据表里的日志）

操作全部记录，记录多处备份
自动计算审核，必要时人工审核

汇率汇率汇率 重要的事说三遍 一定要注意汇率（如果涉及外币）

幂等...
还有存时间戳

银行的套路，出现问题就崩溃，不会带着 bug 运行

跨国电商. 汇率小数点后 10 位了解一下..主要要支持很多币种, 比如 1 USD :13000 INR 的 INR. 1 USD: 23000 的 VND.
稍微金额一大, 肉眼可见的误差.

一定要做好防护，例如熔断，将损失控制在一定范围内。
人是不可靠的，bug 也避免不了，得能够保障整个体系做到允许损失几万、几十万，但绝不能损失上千万

存成分在算汇率的时候要特别注意，"一分钱能换到 0 美分"这种奇葩，反正做分母的时候一定要设置最小值…

@rainysia。。。。。。真没想到啊，，。。。。

注意 事务和锁 select * from id for update 可以参考参考。

数据库的金额字段：用 decimal，控制好小数位数，例如 decimal(20,6)，或者 decimal (20, 8)，按实际需要定制小数位数。
数据库表设计和业务逻辑：账务系统是金融电子系统的核心，账务系统记录了用户、商户、客户等包括平台相关账户（运营账户、营收账户）的当前资产和资产流向。可以先了解复式记账，资产类型，热点账户等。
数据库事务隔离：MySQL 的话，优先 READ-COMMITTED，性能好一些 ，REPEATABLE-READ 对实时对账逻辑设计友好一些。
锁：在性能和安全上做平衡。
对账：如果没有分布式事务的问题，通过账务系统可以进行实时对账。如果涉及到分布式事务、TCC 柔性事务、使用消息队列做事务补偿时，以上情况需要对对账系统做额外设计。
编程语言：使用类似 bigdecimal 库，注意进位方式。
前端展示：建议不要做过多的计算（前后台计算的进位选择不一致，导致展示上不一致），直接让后台返回计算好的结果（字符串）。
技术之外的建议，政策、法律法规、权限等多多做功课。

价格计算千万要放在后台，前端只能传货物 id 和货物数量上来，然后你后端就根据货物 id 从数据库查出货物单价，然后让货物单价*货物数量，得出来的价格（先不考虑折扣之类的附加项）丢给各种支付 api 处理。。。。。。。


还有如果你要和支付宝或者微信支付做对接，你要清楚微信支付和支付宝是以分为单位的，记得区分好元和分，例如你要转 1 块钱给别人，那么你传给支付宝或者微信支付的数据就是 100，我上家公司试过，数据库里面把价格单位定为元，然后一小哥没做转换，看到微信支付支付成功回调返回来的价格字段是 10000 （ 10000 分就是 100 块的意思），自然而然没有做转换所以把价格也存为 10000，导致了一些客户存 100 块能体现 10000 块的 bug。。。。

数据库 decimal . java bigdecimal .
我觉得这个不好的点就是. 写计算公式的时候 代码又臭又长

php 记得只要把单位调低 数字变大就避免了很多问题，

100 分 = 1 元

技术实现问题都不大，准备点钱赔差额就行