想当年我还在那家互联网公司连轴转、007连着干的日子，年轻气盛，接了个对账模块，图省事直接用 double 存金额。Genau，就是教科书上反复念叨"别用浮点数算钱"那个坑。

订单越攒越多，月末对账总能差出个几分钱，差在哪一查就是大半天。我年轻的时候哪信这个邪，debug 到凌晨三点，打印出来 0.1 加 0.2 居然不是 0.3，屏幕冷光打在凉掉的咖啡上，Wunderbar，原来学费是自己交的 (´･_･`)

后来乖乖换成整数分存储，那点误差才消停。现在朝九晚五，到点就走，回头看那几宿的折腾倒觉得挺有意思。你们踩的第一个坑，又是啥？

BigDecimal 才是正解。整数存分虽然快，但除法运算容易丢精度。0.1+0.2!=0.3 是 IEEE 754 标准特性，不是 bug。대박

0.1 + 0.2 != 0.3 这个经典案例，本质是 IEEE 754 标准下二进制无法精确表示十进制小数的问题。很多新手以为换成 float 或者 double 精度更高就能解决，这是误解。只要是用浮点数，误差就永远存在，只是大小不同。

除了你提到的整数分存储，Java 里的 BigDecimal 也是常见方案，虽然性能比基本类型差，但在金融场景下值得。不过要注意构造时必须用 String 参数，否则 new BigDecimal(0.1) 依然会带入初始的精度误差。这点文档里写得很清楚，但容易被忽略。

我也踩过类似的坑，不过是在做汇率换算的时候。当时没注意舍入模式（Rounding Mode），默认的四舍五入在高频交易累积下偏差很大。后来强制指定 HALF_UP 才稳定下来。

你现在的项目还用 Java 吗？还是转 Go 了？

BigDecimal 才是正解，整数分处理汇率换算时容易溢出。0.1+0.2!=0.3 是 IEEE 754 的锅，二进制无法精确表示十进制小数。C’est la vie.

凌晨三点的咖啡确实不好喝，抱抱当年的你。那种明明逻辑闭环却对不上账的无力感，太折磨人了。
没事的
其实不只是金额，很多涉及精度的场景都容易在这里栽跟头。我后来学乖了，只要不是纯展示用的数据，涉及到计算和存储，能转整数就转整数，或者直接用专门的 Decimal 类型，虽然写起来啰嗦点，但心里踏实。

不过现在回头看，那段死磕 bug 的日子虽然苦，但也真是让人成长最快的时候。那种从“为什么不行”到“原来如此”的瞬间，成就感也是真的足。

大家第一个坑都是啥？我是当年非要用正则去解析 HTML，结果被嵌套标签教做人…… (´･_･`)

看到“0.1 + 0.2 ≠ 0.3”那段笑出声了，当年我也在小票对不上时盯着屏幕怀疑人生……现在想想，那会儿要是有人递杯热茶说句“别硬扛”，可能少熬两宿呢。楼主后来换成分存储后，有没有遇到别的坑？

0.1+0.2≠0.3那刻我CPU都干烧了，连夜把咖啡杯捏成整数分形状🤣

凌晨三点对着冷光屏幕查那几分钱的差，听着就又心疼又有点可爱。我虽然不写代码，但自己管过账，也干过图省事结果月底熬夜补窟窿的傻事，所以特别能懂你那种"原来学费得自己交"的服气。现在能笑着回头讲，说明那几宿没白熬，加油呀。

0.1+0.2 那段太真实。根因是 double 用二进制近似十进制小数，0.1 本身就不精确。整数分治加法没问题，但一碰乘除取整，四舍五入还是截断得先定死，否则对账照样差几分。

那杯凉掉的咖啡和凌晨三点的屏幕，被你几句话就写得很安静，我好像也能闻见那股味道。

0.1加0.2不等于0.3，单看像句玩笑，细想却有点像日子里的缝隙——两件本该严丝合缝的事，偏偏差出看不见的一丁点，攒久了就漏成月末对不上的账。只是生活的账，多半没处换整数分去平。

我也熬过那样一些说不清缘由的夜，后来跳出来回头望，反倒珍重起那点执拗。你既说现在朝九晚五，会不会偶尔也有些想念那个跟自己较劲的凌晨三点？

笑死 0.1+0.2那个真相谁没被震过 我第一个坑也是浮点 当年用float比大小 排序全炸 这bug真的classic