涉及金钱存储或计算操作时，你们一般都使用什么数据类型

乘以 100

一万倍，长整型

我见过好多用 double 或者 String 的, 但是我觉得用分做单位,整数型最稳,除专业金融领域, 分单位足够用了

BigDecimal 一把梭，不要想自己搞什么花花肠子

金额使用 BigDecimal，金融行业 4 位小数，非金融 2 位小数。单价、利率什么的也用 BigDecimal，具体几位小数看需求。

用分一定要小心，见过本来要配置 100 元的，没加两个 00，变成 1 块。

double 、float 仅用于科学计算，用在业务系统里面就是搞笑。

用 string 就更搞笑了，完全是治标不治本。

不能一概而论，算加减法用定点数没有问题，但利息什么的要用乘法的时候，还是得用浮点数

bigdecimal

用 double 做清结算之类的 没被人砍死吗？
还是想留后门自己薅羊毛

存储用分…计算的话最后用减……

数据库落库 decimal
业务里各种千奇百怪的要求,四位小数,两位小数,不要小数.都要涉及取整操作.真烦

我要给 double 正名！按说精度也有 14 位，怎么就不能当存储类型了？
统计有误差，是因为有计算中有误差会逐渐累计！你把误差去掉，或者用高精度大数类型替代一下就可以。
光保存是没问题的。

decimal，，，

不用 decimal 早晚有问题

两位小数，decimal 逃

decimal

@3dwelcome 放屁，一看就是没踩过坑的，差一分财务都会对出来好不

BigDecimal 一把梭，多币种清算业务毫无压力。

万万没想到，居然还有这么多人写的系统用浮点类型，惊到了

@3dwelcome #14 学完了 IEEE 754 再来回帖吧……

@3dwelcome #14 你在逗我？？？？来电商三天包你下岗……

@xuanbg #8 原文：“用 string 就更搞笑了，完全是治标不治本。”
回复：

我倒觉得如果不用 decimal 而用 ` 两位小数的 string `或者 `乘以 100 的 integer `，貌似也都可以，因为好像也不会碰到无脑 double 浮点数运算的误差问题。

@zjsxwc string 看上去是没有精度问题，但你总要计算的吧，转 double 计算吗？所以我说「治标不治本」

老实说目前用的就是 Double 存储的，计算的时候，用用 BigDecimal 包裹，处理了下精度问题，那位老哥帮忙科普下，这样有啥风险

@xuanbg 人家都用 String 存储了你非要转 Double 做运算，不知道谁傻。

@susunus 浮点数只能表示数轴上的离散点，计算结果只能近似到最近的点，除非刚好能用 2 进制表示，例如 0.5，否则都是近似值。数轴上的点数量是无穷的，用有穷的浮点数来做计算，有偏差的概非常大。所以浮点数只能用在能容忍偏差的场景，比如图形绘制。除了数值偏差，浮点数还有众所周知的不能用==判定相等的特性。

小数字用 decimal，大数字用 string，bytes 之类的，自己设计运算方法。
存储的和传输内容都是整数，只有显示时用 string 形式的浮点数。

参考 Money 模式，底层一般用 64 位的整型就可以了；如果长整型还不够用，那就考虑 GMP 吧。

@3dwelcome #14 以前写的代码用 double，突然发现数据库里面存的数据变成了 100.00000009，哈哈哈哈哈

@Building string 能做四则运算？？？

@xuanbg 可以

@xuanbg decimal 也是 string 按我了解的 多种语言的高精度计算貌似都用到了字符串做中间过程

并不需要转数值再计算，可以看一下这个 https://oi-wiki.org/math/bignum/

某金融，13 位整形，minor unit，配合 decimal flag，然后转化成 major unit 。
比如，美金，decimal flag 就是 2，所以，100 minior unit = 1 USD major unit
越南盾，decima flag 就是 0，10000 minor unit 就是 10000 越南盾元。

通货膨胀，经常爆了。。。

c# Decimal 值类型表示介于正 79,228,162,514,264,337,593,543,950,335 和负 79,228,162,514,264,337,593,543,950,335 之间的十进制数字。
sql server money -922,337,203,685,477.5808 到 922,337,203,685,477.5807 （对于 Informatica，为 -922,337,203,685,477.58 到 922,337,203,685,477.58 。Informatica 仅支持两位小数，而不是四位。）

我想不出来什么应用可以超出它的范围

，楼上的通货膨胀没有考虑到，以百万为货币单位的货币是很容易爆。。。

@PopRain 64 位整型，最大可以支持 900 万万亿，算上通货膨胀，也基本够用。真要是超出这个那就上 GMP ？

Numeric(19, 2)

@mitu9527 用整数也有问题，小数点的位置问题，常用货币 1 JPY=0.009357 USD，还有一些以亿元为单位的货币

@xuanbg
当然可以。不仅四则，乘方、开方、对数、三角函数都可以。
最简单的方法，模拟人类手工笔算一样操作每一位数就好了。只要资源足够，理论上没有精度上下限。

@xuanbg String 不能做四则运算......按你这个意思你是不是觉得计算机只要超过 UIntMax 的整数就没办法表示了？

一帖显示出 v2 上有多少人基本功不过关

用 Java 的话，有 Java Money 标准(JSR354)，和 Java DateTime 一个时期的产品，可惜一直没进 JDK 。
但是这个项目已经很成熟，https://javamoney.github.io/ ，官方提供了 JPA 扩展，也就是说直接用关系数据库没问题的。
@cigarzh
@xuanbg

遇到金融数据，自然想到 BigDecimal 当然是最基本的常识。但是 Money 还包括了相应 Currency 的处理，特别是国际化方面。

@PopRain 从数学角度看，不管你怎么处理总会存在误差，1/3 永远都除不尽，总是在某个位置要截断。我们要做的是把问题解决到可接受范围内，而不是完美解决。所以靠长整型和 Money 模式可以解决绝大多数问题，性能也还不错；如果业务真的要处理津巴布韦这种货币了，用 GMP，支持任意长度的整型，本质上是字符串，就是性能差。

@mitu9527 我是支持用 Decimal 的，基本在业务范围内的问题都可以解决，而整数很多需要自己处理，遇到某些不熟悉的程序员，可能出现大问题，譬如上面说的 1 元=100

@mitu9527
@hantsy
@Building 你们啊，用第三库或者自己造个轮子让 string 能够进行计算我会不懂？ BigDecimal 本身也是一个轮子，内部的实现还是 int 和 long 。

难道你们还能造个不用 int 、long 、double 、float 的轮子不成？

没研究，但是如果强行用 double 的话，我感觉，除了：

1.误差好像基本上都是小于 10^-7 级别 (0.0000001) 的误差，每次计算完后都按照要求精度 round 一下应该可以解决这个问题；
2.比较相等 == 的时候需要额外处理下。

还有哪些需要注意的吗。

@xuanbg 原谅 PHP 太 low，没有 BigDecimal，只能用 GMP 或者 BC Math 扩展。然后最懒的方式就是用现成的、实现 Money 模式的库，还可以搞定币种、最小金额单位和分配等问题。

用 int，不同币种可以指定价格等级，类似 appstore

不然等着被疯狂薅 1 分钱羊毛

@3dwelcome 其实我原来在银行的时候，非核心的外部系统，C 开发的，double 用来处理也没啥问题。基本上有效位数是够的。

Long,经过我们系统的大概千亿级

运算还是存储，存储的话，什么都行。涉及运算要么用大数类，要么单位分 整数运算。

好奇为什么 Decimal 不是标准答案

decimal

不知道楼上在喷什么，人家说用 double 存储，存储有问题吗？计算的时候拿出来怎么样精确计算各有各的方法，谁都知道 double 直接算会出问题。

BigDecimal

@sxd96 当然有问题，因为 double 的 1 不等于 int 的 1 啊

int string 或者 double 都行，只要处理得当。但是最后你会发现，你重新发明了 decimal 的轮子

@cubecube double 到万亿这个数量级精度就不够了，比如 5 万亿加 0.1 分

@sxd96 存储的就是不精确的啊. 你肉眼看到是 0.5, 实际数据并不是刚刚好 0.5 啊. 是 toString 的算法让你觉得存储的是精确的而已.

@xuanbg

@joesonw

double 能不能确保存储进去和读取出来的值是一样的？

toString 将 double 解析成我肉眼看见的值，我在用 bigdecimal 计算的时候能不能确保转换后的值和 toString 的值是一样的？
知道个 overflow underflow 就看哪都是问题了？用脑子再多想两遍。

@sxd96 自己更正一点。
double 的 frac 总共 52bit，精确表示数值加上前面的 sign 1bit 总共能精确表示正负 2^52 。
假设再加上可能有的 4 位小数，能精确表示的金额只有正负 2^48=281,474,976,710,656 以及后面的 4 位小数。适用场景大大受限。

事实上不做计算，仅做储存，能精确表示的范围也是相对固定的。但是我认为这个范围应该是够绝大多数公司撑到死了。

@sxd96
脑子瓦特了，再更正一点。
如果要准确表示上面假设里说的 4 位小数，要 10bit 不是 4bit 。那么金额的整数部分就只有 2^42 = 4,398,046,511,104 。

在精确表示的范围内直接用 double 做算术运算也不会有问题的，也用不到什么 bigdecimal 。但是这个范围确实比我想当然的小了不少。4 个小数点存在的情况下，只能做到 4 万亿内的精确。

但是上面说的所谓 0.5 存着不是 0.5 就是开玩笑，double 的 1 那就是 1 。
用 decimal 肯定是第一反应也是最好的选择，当然没意见。但是看着这么多瞎说 double 溢出的，就很让人奇怪。

必须用整形，至于乘 100 、乘 10000 、乘 1000000，看项目精度要求

金额还是统一 BigDecimal, 用别的搞法，出现问题，涉及到钱的一般都是大锅，望慎重

@sxd96
4 位小数应该是 14bit 吧？
只是存储问题当然有限，关键是实际计算的中间过程，容易出现防不胜防的错误判断、超出范围和舍入误差累积
参见： http://www.lahey.com/float.htm

财务金额要是用 decimal 或者 float 的，一看就知道没有被四舍五入收拾过得！
财务上差一分钱会计和出纳都会拉着你查账查到半夜，而最后的结果往往都是四舍五入导致的！
所以！一定要用 int ！一定要用 int ！一定要用 int

@3dwelcome 兄弟别在这里误导人！到时候因为四舍五入的问题查账查到半夜的不是你，而是停了你建议用 double 的兄弟！

货币都是有定义最小单位的

为何要用浮点数?

自打做系统，金额类的用的一直是 bigdecimal 。但是我们数据库保存的是元，总感觉别扭

@darrenfang 100.00000009 这种末尾本来就是计算误差，是随机数，你取出来的时候，直接 round 后断尾，精确度就完全没问题。
double 有效数是 14 位，不需要用全，保证前 12 位没有数字误差，就可以了。
IEEE 数据格式本来就是一个工具，在不同人手里，呈现的结果并不一样。代码是死的，人是活的，工具不趁手可以稍加改造。有坑多研究，总有绕过去的办法。
码农的天职不是无脑调用 API，而是解决各种棘手问题。

@ytmsdy 四舍五入还不是因为计算精度误差。我说了 double 只是储存，如果计算累积精度不够，可以找高精度类来替代。
你们对 double 内部格式都没有真正理解，在没有小数位的情况下，整数数值储存部分 bit，和 INT 在二进制上表示，是一模一样的。
比如 double 存 1024 和 int 存 1024，内部就是一样的。只不过 double 里有指数位的存在，会对比特位进行 shift 操作。

其实 String 就行，平时真要计算的时候，使用 joda Money 类。

数据存储使用的金额单位是分,代码中金额操作使用 BigDecimal;