2022 年我做一个带账务的系统——要记每一笔钱的进出、每天还要对账。存金额、算金额这件事,我压根没多想。第一版我做得很省事:金额不就是个数字?用 float 存,加加减减不就完了?余额是个 float,每来一笔流水就 += 一下,要展示就直接打出来。本地开发时——真不错:我自己造几笔流水测,加出来的数、对账的数,看着都对,几行代码搞定。我心里很踏实:"金额嘛,不就是个数字?"可等这个系统真正上线、记了成千上万笔真实流水,一串问题冒了出来。第一种最先把我打懵:某天对账,把所有流水加起来的总额,和账面余额,差了一分钱。就一分钱,可账是账,我查了整整三天——每一笔流水单看都对,可加到一起就是差一分,我找不到那一分钱是从哪冒出来的。第二种最离谱:有个分摊的功能,把 100 元平摊给 3 个人,每人 33.33 元,可 33.33 乘以 3 等于 99.99——那剩下的一分钱,系统里没有任何一个人认领,它就那么凭空消失了。第三种最说不清:同一笔钱,在不同的模块里算出了两个值——一个模块把零头截断了,另一个模块四舍五入,谁也说不清哪个才算数。第四种最隐蔽:金额从接口传进来、存进数据库、再读出来展示,在 JSON 和数据库之间来回转了几道,某些金额的末位悄悄地变了——19.99 读出来成了 19.989999999。我盯着这一连串问题想了很久才彻底想明白,第一版错在一个根本的认知上:我以为"金额,就是一个数字,用 float 存就行"。这句话把金额,当成了和"温度""身高""速度"一样的、可以容忍微小误差的普通数值。可它不是。金额不是一个"普通的数字"——它是一种必须精确、有固定小数位、有明确舍入规则的特殊的量。float(浮点数)这个类型,是为科学计算里那种"连续的、可以容忍微小误差的量"设计的:它在底层用二进制来表示小数。而问题恰恰出在这里——像 0.1、0.2 这样的十进制小数,换算成二进制是无限循环的,float 根本存不下,它存的从来就不是 0.1,而是一个无限接近 0.1、但不等于 0.1 的近似值。对科学计算,这点误差微不足道;可对金额,这点误差是致命的:它会在成千上万次加减运算里一点一点累积,最后就变成了对账单上那"凭空多出来、又怎么都找不到"的一分钱。所以金额的正确表示,根本不该用 float。要么用"最小货币单位的整数"——把元换算成分,用整数存,从根上就不碰小数,也就没有任何浮点误差;要么用十进制定点数 Decimal,它就是专门为"精确的十进制运算"造的。而且金额的运算,远不只是"加减乘除"那么简单——它还必须回答三个 float 从来不会逼你回答的问题:这个数该保留几位小数、除不尽的时候按什么规则舍入、舍入产生的那个差额到底归谁。真正做好金额计算,核心不是"用 float 存个数字",而是用整数分或 Decimal 精确表示金额、把舍入规则显式钉死、让分摊除不尽的余数有人兜底、在序列化与存储的每一道关口上都不丢精度。这篇文章就把金额计算梳理一遍:为什么"用 float 存金额"是错的、怎么用整数分存储、怎么用 Decimal 做运算、舍入为什么必须显式、除法与分摊的余数怎么处理,以及货币单位、序列化、数据库类型、汇率换算这些把金额计算真正做扎实要避开的坑。
问题背景
先把那串问题的现象和我的误判讲清楚,后面所有的设计都是冲着纠正这个误判去的。
现象:一套"用 float 存金额"的账务系统,在记了大量真实流水后冒出一串问题:对账时总额和余额差了一分钱、查三天查不出;分摊 100 元给 3 个人,剩下一分钱凭空消失、无人认领;同一笔钱在不同模块因舍入方式不同算出两个值;金额经 JSON 和数据库来回转,末位精度悄悄漂移。
我当时的错误认知:"金额,就是一个数字,用 float 存就行。"
真相:这个认知错在它用错了"数字"这个类型。"金额就是个数字"——这句话本身没说错,错在它默认"数字就该用 float 存"。float 是一种为科学计算设计的类型:它要表示的是温度、距离、速度这类连续的、本来就带测量误差的量,所以它在底层用二进制做近似表示,牺牲一点精度换取极大的范围和速度——对这些量来说,这个取舍非常划算。可金额是另一种完全不同的量:它是离散的(最小就到分,没有半分)、它要求绝对精确(差一分都是账务事故)、它有固定的小数位和明确的舍入规则。拿一个"为容忍误差而生"的类型,去装一个"绝不容许误差"的量——错配就在这里。一旦你看清了这一点,那串问题就都有了解释:对账差的一分钱,是 float 的二进制近似误差累积出来的;分摊消失的一分钱,是除不尽时没人去管那个余数;两个值,是舍入规则没被钉死、各模块各凭默认;精度漂移,是金额在传输存储中又被转回了 float。问题的根子清楚了:这不是"要不要多保留几位小数"的小修补,而是要换一个根本的认知——金额是一种特殊的量,它需要一种特殊的、精确的表示方式,以及一整套围绕"精确"展开的运算纪律。
要把金额计算做对,需要几块认知:
- 为什么"用 float 存金额"是错的——float 为容忍误差而生,金额绝不容许误差;
- 整数分存储——把金额换算成最小货币单位的整数,从根上不碰小数;
- Decimal 运算——需要小数运算时,用专为精确十进制设计的 Decimal;
- 显式舍入——保留几位、按什么规则舍入,必须写死,绝不靠默认;
- 除法与分摊——除不尽产生的余数,必须明确分配给谁,合计严格相等;
- 货币单位、序列化、数据库类型、汇率换算这些工程坑怎么处理。
一、为什么"用 float 存金额"是错的
先把这件最根本的事钉死:"用 float 存金额"错在它对 float 的本质有个误解。很多人以为 float 的小数就是我们写在纸上的那个十进制小数,只不过偶尔会有"舍入误差"。不是的——float 在底层是用二进制来表示小数的,它能精确表示的,只有那些能写成二进制有限小数的数,比如 0.5、0.25、0.75。而像 0.1、0.2、0.3 这些我们天天在用的十进制小数,换算成二进制,是无限循环小数——就像 1/3 在十进制里写不尽一样。float 存不下一个无限循环的数,它只能存一个截断后的、无限接近但并不等于 0.1 的近似值。所以当你写下 0.1 + 0.2,计算机做的其实是"两个近似值相加",结果自然也是个近似值——它不等于 0.3,而是 0.30000000000000004。这不是 bug,这是 float 这个类型的设计本来如此:它生来就是为"可以容忍微小误差"的科学计算服务的。问题在于,金额是一个绝不能容忍误差的量。单看一笔,这点误差小到你根本看不见;可一旦成千上万笔金额在 float 上反复加减,每一次都带着一丁点近似误差,这些误差就会累积、会放大,最后汇成对账单上那笔"差了一分、却怎么都查不出来源"的钱。
下面这段代码,就是我那个"本地怎么测都对、上线对账就差钱"的第一版:
# 反面教材:用 float 存金额、做运算
balance = 0.0
def add_payment(amount):
global balance
balance += amount # 破绽 1:每一次 float 加法都带一丁点近似误差
# 对账:把每一笔流水加起来,理论上应该严格等于账面余额
total = 0.0
for p in payments:
total += p.amount # 破绽 2:成千上万笔累加,误差越滚越大
print(total == balance) # 破绽 3:很可能打印 False,差的就是那"一分钱"
print(0.1 + 0.2) # 0.30000000000000004 —— float 的本来面目
这段代码在本地开发时表现不错,因为本地我自己造的测试流水,数量少、数额也"整"——加个三五笔、还多半是整数,误差小到压根冒不出头。它的问题不在某一行语法上——balance += amount、total += p.amount,语法都对——而在它用 float 这个"为容忍误差而生"的类型,去扛一个"绝不容许误差"的任务:balance 和 total 从第一天起,存的就不是精确的金额,而是一串近似值;它们各自经历的加法次数、加法顺序又不一样,累积出来的误差也不一样——于是 total == balance 这个本该永远成立的等式,就那么悄悄地不成立了。这四个破绽对应的,正是开头那四类问题。问题的根子清楚了:做对金额计算,第一步不是"多留几位小数""对账时容忍一点误差",而是从一开始就别用 float——给金额换一种精确的表示方式。下面五节,就是这种精确表示,以及围绕它的运算纪律。
二、整数分存储:把金额从"小数"变回"整数"
第一种、也是最彻底的精确表示:根本不碰小数。金额之所以会有浮点误差,是因为它带小数;那如果把"元"换算成"分"——1 元就是 100 分——金额就变成了一个纯粹的整数,而整数的加减,是计算机能百分之百精确完成的:
from decimal import Decimal
class Money:
"""金额用"分"这个整数存:从根上不碰小数,也就没有浮点误差。"""
__slots__ = ("cents",)
def __init__(self, cents):
if not isinstance(cents, int):
raise TypeError("Money 只接受整数分,别把 float 塞进来")
self.cents = cents
@classmethod
def from_yuan(cls, yuan_str):
"""从"12.34"这样的字符串构造:走字符串而非 float,精度才不会丢。"""
d = Decimal(yuan_str)
return cls(int(d * 100))
def to_yuan_str(self):
"""展示时再换算回"元.角分":整数除法和取模,精确无误。"""
sign = "-" if self.cents < 0 else ""
v = abs(self.cents)
return f"{sign}{v // 100}.{v % 100:02d}"
金额一旦是整数,它的加减就简单到不可能出错——就是整数加减:
def __add__(self, other):
return Money(self.cents + other.cents) # 整数加法,精确,永不累积误差
def __sub__(self, other):
return Money(self.cents - other.cents)
def __eq__(self, other):
# 两笔钱相等 = 分数完全相同,这个判断是百分之百可靠的
return isinstance(other, Money) and self.cents == other.cents
这里的认知要点是:整数分存储的思路,本质上是"绕开问题",而不是"解决问题"——而这恰恰是它的高明之处。浮点误差的来源是"小数",那我就让金额压根不以小数的形式存在:在系统内部,金额从头到尾都是一个叫做"分"的整数,只有在最后展示给人看的那一刻,才把它换算回"元.角分"的样子。这样一来,系统里所有的金额加减,就都是整数加减——而整数运算是计算机唯一能做到绝对精确、绝对没有近似误差的算术。这个方案有两个细节是关键。第一,Money 的构造函数严格只收整数 cents,一个 float 都不许进——因为只要有一个 float 漏进来,误差就跟着进来了,这道类型检查就是一道"别让小数混进来"的关卡。第二,from_yuan 从字符串构造时,中间过的是 Decimal,而绝不是 float——如果你写 int(float("12.34") * 100),那个 float("12.34") 本身就已经是近似值了,乘 100 之后可能得到 1233.9999999,int() 一截断就成了 1233,平白丢了一分钱。整数分方案能成立,前提就是"从外部数据进入系统的那一刻,就走精确通道、绝不沾 float"。整数分能解决绝大多数场景,可有些运算天生会产生小数——这要靠下一种表示。
三、Decimal 运算:需要小数时的精确算术
整数分很彻底,但它不擅长一类运算:乘法和除法。算个税率、算个折扣、算个利息,结果天然就带小数,硬塞回整数分会很别扭。这时候需要第二种精确表示——Decimal(十进制定点数)。它和 float 最根本的区别是:它在底层就是按十进制存的,你写 Decimal("0.1"),它存的就是精确的 0.1,不是近似值:
from decimal import Decimal
# 对的:用字符串构造 Decimal —— 你写的是多少,它存的就精确是多少
a = Decimal("0.1")
b = Decimal("0.2")
print(a + b) # 0.3 —— 精确,没有那个 0.30000000004 的尾巴
# 错的:用 float 构造 Decimal,float 自带的误差会被原样搬进来
bad = Decimal(0.1)
print(bad) # 0.1000000000000000055511151231257827021181583404541015625
# 教训:构造 Decimal,永远从字符串或整数来,绝对不要从 float 来
good = Decimal("0.1") # 字符串 —— 对
also_good = Decimal(10) # 整数 —— 对
这里的认知要点是:Decimal 和 float,虽然都能装小数,但它们是两种世界观完全不同的类型。float 的世界观是"用二进制近似,换取速度和范围",它默认你能容忍误差;Decimal 的世界观是"按十进制精确表示,哪怕慢一点",它默认你一分一厘都不能错。选 Decimal,就是选了后一种世界观——这正是金额需要的。但用 Decimal,有一个坑必须刻进肌肉记忆里:构造它的时候,绝对不能从 float 来。你看上面那个 Decimal(0.1),结果是一长串 0.100000000...0555——为什么?因为 Decimal(0.1) 这个写法,是先让 Python 算出 0.1 这个 float(它本来就是个近似值),再把这个近似值精确地转成 Decimal。Decimal 忠实地、精确地记下了那个 float 的近似误差,一位不差。这就荒唐了:你用 Decimal 是为了精确,结果在构造的第一步就把 float 的误差请了进来。正确的姿势只有一种——构造 Decimal 永远从字符串或整数来:Decimal("0.1") 是把"0.1"这个字符直接解析成十进制的 0.1,中间没有 float 插一脚,精度才真正干净。一句话:Decimal 能不能精确,不取决于 Decimal 本身,取决于你喂给它的东西干不干净。有了 Decimal 能算小数,可小数算出来往往位数很长,得把它收拾干净——这要靠下一步。
四、显式舍入:把"四舍五入"这件事钉死
用 Decimal 一算税、一算折扣,结果常常是 19.985、33.333333 这样位数很长的小数。金额不能这么放着——它必须被收拢到固定的小数位(人民币就是 2 位)。这一步叫舍入,而舍入这件事,必须显式地、明确地写出来:
from decimal import Decimal, ROUND_HALF_UP
def round_money(d, places=2):
"""金额舍入必须显式:写明保留几位、用哪种舍入规则,绝不靠语言默认。"""
quant = Decimal(10) ** -places # places=2 时,即 Decimal('0.01')
return d.quantize(quant, rounding=ROUND_HALF_UP)
print(round_money(Decimal("19.985"))) # 19.99 —— 四舍五入,规则写死
print(round_money(Decimal("33.333333"))) # 33.33
print(round_money(Decimal("2.005"))) # 2.01 —— 不受 float 误差干扰
这里的认知要点是:舍入这件事,最大的坑不是"算错",而是"不同的地方用了不同的规则,自己还不知道"。舍入的规则不止一种:有"四舍五入"(ROUND_HALF_UP),有"四舍六入五成双"的银行家舍入(ROUND_HALF_EVEN),有直接截断(ROUND_DOWN),还有向上取整(ROUND_UP)。同一个 19.985,这几种规则会给出 19.99 或 19.98 两个不同的答案。如果你在代码里从不显式指定 rounding,而是依赖某个函数的默认行为——比如 Python 内置 round() 用的其实是银行家舍入,而很多人下意识以为它是四舍五入——那么不同的模块,就会在你毫不知情的情况下,用着不同的舍入规则。结果就是开头那第三个问题:同一笔钱,这个模块算出一个值,那个模块算出另一个值,而且每个模块单看都"没错"。所以金额的舍入,必须满足两条:第一,每一次舍入都显式写出 rounding=某种规则,绝不留给默认;第二,整个系统统一用同一种规则(并和业务、财务确认过)。quantize 这个方法之所以适合金额,就是因为它逼着你把"保留几位"和"什么规则"两个参数都明明白白地交代清楚——它不给你"靠默认蒙混过去"的机会。舍入不可怕,可怕的是不受控、不一致的舍入。舍入解决了"一个数怎么收拢",可金额运算里还有一个更麻烦的——除法。
五、除法与分摊:差额必须有人兜
金额里最容易出事的运算,是除法——尤其是分摊:把一笔钱分给几个人。100 元分给 3 个人,每人 33.33 元,可 33.33 × 3 = 99.99——那一分钱去哪了?这就是开头那个"凭空消失的一分钱"。正确的分摊,不能让任何一分钱消失:除不尽产生的余数,必须明确地分配给某些人,保证各份合计严格等于总额:
def allocate(total_cents, weights):
"""按权重把一笔钱分摊下去:除不尽产生的余数,一分一分补给前几份。"""
total_weight = sum(weights)
# 第一步:按权重做整数除法,得到每份的"基础额"
shares = [total_cents * w // total_weight for w in weights]
# 第二步:基础额求和,和总额一比,差出来的就是整数除法丢掉的余数
remainder = total_cents - sum(shares)
# 第三步:余数有几分,就给前几份各补一分 —— 一分都不让它消失
for i in range(remainder):
shares[i] += 1
return shares
print(allocate(10000, [1, 1, 1])) # [3334, 3333, 3333] —— 合计正好 10000
print(allocate(10000, [1, 1, 2])) # [2500, 2500, 5000] —— 合计正好 10000
下面这张图,把分摊这个过程画出来:
这里的认知要点是:分摊的核心,是想清楚一件事——"除不尽"是常态,不是异常。100 除以 3 除不尽,7 元的折扣分摊到 3 件商品上除不尽,这种事在账务里每天都在发生。错误的做法,是先算出 100 / 3 = 33.33,再把这个 33.33 当成每个人的份额——这一步,你已经在不知不觉中把那"分不尽的一分钱"弄丢了,因为 33.33 × 3 永远回不到 100。正确的做法,是换一个思路:不要先算"每份是多少"再去乘,而是把分摊看成"一个总数,要被完整地拆开、且拆开后必须能严丝合缝地拼回去"。allocate 做的就是这件事:先用整数除法给每份一个基础额(这一步会丢下一个余数),然后关键的一步——把丢下的余数精确地算出来,再一分一分地补回到前几份里去。这样,每一份可能比"理论平均值"多一分或少一分,但所有份额加起来,严格、精确地等于总额,一分钱都没有消失。这背后是一条金额运算的铁律:任何一次拆分,拆出来的所有部分加起来,必须能精确地还原成拆分前的总数。守住这条铁律,你的账才永远是平的。金额表示和运算的主干都齐了,最后是几个把金额计算真正用到生产里才会撞见的工程坑。
六、工程坑:货币单位、序列化、数据库类型、汇率
主干之外,还有几个工程坑,不处理就会让你的金额计算在边角上漏钱。坑 1:别假设所有货币都是 2 位小数。人民币、美元是 2 位小数,可日元没有"分"、是 0 位小数,科威特第纳尔是 3 位小数。"金额 × 100 换算成分"这种硬编码,一遇到非 2 位小数的币种就错了。币种的小数位要查表:
from decimal import Decimal
# 不同币种的小数位不一样:绝不能假设所有货币都是 2 位小数
CURRENCY_EXPONENT = {
"CNY": 2, # 人民币:最小单位"分",2 位小数
"USD": 2,
"JPY": 0, # 日元:没有"分",0 位小数
"KWD": 3, # 科威特第纳尔:3 位小数
}
def to_minor_units(amount_str, currency):
"""把金额字符串换算成该币种的最小单位整数(分 / 厘 / 整元)。"""
exp = CURRENCY_EXPONENT[currency]
d = Decimal(amount_str)
return int(d.scaleb(exp)) # scaleb(exp) 即把小数点右移 exp 位
坑 2:金额进 JSON,要用字符串,别用 number。JSON 里的 number 类型,大多数解析器都会把它解析成 float——金额一旦在序列化时变成 JSON number,接收方一解析,它就又变回 float、精度就丢了。金额在 JSON 里应该是字符串:
import json
def dump_money(cents):
"""金额进 JSON:转成字符串。JSON 的 number 会被解析成 float,精度必丢。"""
yuan = Decimal(cents).scaleb(-2)
return json.dumps({"amount": str(yuan), "currency": "CNY"})
# 正确:{"amount": "19.99", "currency": "CNY"} —— 字符串,精度完好
# 错误:{"amount": 19.99} —— 这个 number 过一次 JSON 解析,就成了 float
坑 3:数据库金额列,用 DECIMAL,绝不用 FLOAT。道理和前面一样:列类型一旦是 FLOAT 或 DOUBLE,金额存进去的那一刻就已经是近似值了。金额列必须用定点数 DECIMAL:
-- 对的:金额列用 DECIMAL 定点数,精确存储,不丢精度
CREATE TABLE orders (
id BIGINT PRIMARY KEY,
amount DECIMAL(18, 2) NOT NULL, -- 18 位有效数字,固定 2 位小数
currency CHAR(3) NOT NULL
);
-- 错的:用 FLOAT / DOUBLE 存金额 —— 存进去就是近似值,对账差钱的源头
-- amount FLOAT NOT NULL
坑 4:汇率换算后,要立刻舍入到目标币种的精度。金额乘以汇率,结果几乎一定是个长长的小数。换算完必须马上按目标币种的小数位舍入,别让这个长尾小数继续参与后面的运算:
from decimal import Decimal, ROUND_HALF_UP
def convert(cents, rate, to_currency):
"""汇率换算:乘完汇率,立刻按目标币种精度舍入,不留长尾小数。"""
raw = Decimal(cents).scaleb(-2) * Decimal(str(rate))
exp = CURRENCY_EXPONENT[to_currency]
rounded = raw.quantize(Decimal(10) ** -exp, rounding=ROUND_HALF_UP)
return int(rounded.scaleb(exp)) # 落到目标币种的最小单位整数
坑 5:不同币种的金额,绝不能直接相加。100 日元和 100 美元不是一回事,把它们的数值直接相加毫无意义。金额对象里必须带上币种,做加减时先校验币种一致,不一致就报错。坑 6:别用 == 比较两个 float 金额。这是 float 误差的直接后果——0.1 + 0.2 == 0.3 是 False。当然,你一旦改用整数分或 Decimal,这个坑自然就不存在了,这也正是放弃 float 的又一个理由。坑 7:中间计算别过早舍入。一长串运算,只在最终结果落地时舍入一次——如果每一步中间结果都舍入,这些舍入误差会累积成一个不小的偏差。原则是:过程中保留足够精度,只在最后一步、金额要落库或要展示时,才舍入。
关键概念速查
| 概念 / 手段 | 说明 |
|---|---|
| 用 float 存金额的错 | float 用二进制近似十进制小数,金额绝不容许误差 |
| 误差会累积 | 单次误差极小,成千上万次加减后汇成对账差额 |
| 整数分存储 | 把元换算成分,用整数存,从根上不碰小数 |
| Decimal 定点数 | 需要小数运算时用 Decimal,精确的十进制算术 |
| Decimal 别从 float 构造 | Decimal(0.1) 会带进 float 误差,必须从字符串构造 |
| 显式舍入 | 保留位数与舍入规则都写死,绝不依赖语言默认 |
| 舍入规则要统一 | 四舍五入与银行家舍入结果不同,全系统须一致 |
| 分摊余数要兜底 | 除不尽的零头补给前几份,各份合计严格等于总额 |
| 货币单位不固定 | 日元 0 位、第纳尔 3 位,小数位要查表不能硬编码 |
| 序列化与存储不丢精度 | JSON 用字符串、数据库用 DECIMAL,绝不用 float |
避坑清单
- 别用 float 存金额,它为容忍误差而生,而金额绝不容许误差。
- 金额优先用整数分存储,换算成最小货币单位,从根上不碰小数。
- 需要小数运算时用 Decimal,它专为精确十进制算术设计。
- 构造 Decimal 永远从字符串或整数来,绝不从 float 来。
- 金额舍入必须显式写明保留位数和舍入规则,绝不靠语言默认。
- 全系统统一一种舍入规则,并和业务财务确认过。
- 分摊除不尽的余数必须分配到位,各份合计严格等于总额。
- 币种小数位查表处理,别假设所有货币都是 2 位小数。
- 金额进 JSON 用字符串,数据库金额列用 DECIMAL,都别用 float。
- 中间计算保留足够精度,只在最终落库或展示时舍入一次。
总结
回头看那串"对账差一分钱、分摊丢一分钱、同一笔钱两个值、精度悄悄漂移"的问题,以及我后来在金额计算上接连踩的坑,最该记住的不是某一个舍入函数的写法,而是我动手前那个想当然的判断——"金额,就是一个数字,用 float 存就行"。这句话错在它给金额选错了类型。我以为数字就该用 float 存,金额是数字,所以金额就该用 float 存。可我忽略了一件最要紧的事:float 这个类型,是为科学计算里那种"连续的、可以容忍微小误差的量"造的——它用二进制近似表示小数,拿一点精度换速度和范围。而金额是一种性质完全相反的量:它离散(最小到分)、它要求绝对精确(差一分都是事故)、它有固定的小数位和明确的舍入规则。用一个"为容忍误差而生"的类型,去装一个"绝不容许误差"的量,这个错配,本地开发时根本看不出来——因为本地的测试数据少、误差还没来得及累积;它只会在成千上万笔真实金额反复加减之后,以对账单上那笔查不出来源的钱,把账结给你。
所以做对金额计算,真正的功夫不在"写一个舍入函数"那几行上。舍入函数本身不难。真正的功夫,在于你要从一开始就承认"金额是一种特殊的量,需要一种特殊的、精确的表示",然后围绕"精确"建立起一整套运算纪律:你不能用 float,就用整数分,把金额变回计算机能精确处理的整数;要算小数,就用 Decimal,而且只从字符串构造它;数要收拢,就显式地写明保留几位、用哪种舍入规则;遇到除不尽,就把余数一分不少地分配到位、让合计严格相等;而到了序列化、存数据库这些边界上,你还要处处守住,别让金额又偷偷变回 float。这篇文章的几节,其实就是顺着这套纪律展开的:先想清楚"用 float 存金额"为什么错,再讲整数分怎么存、Decimal 怎么算、舍入为什么必须显式、分摊的余数怎么兜,最后是货币单位、序列化、数据库、汇率这几个把金额守扎实的工程细节。
你会发现,金额计算这件事,和现实里"一个账房先生怎么管一本账"完全相通。一个马虎的账房会怎么记账?他嫌零头麻烦:几角几分的,"差不多就行",今天的零头随手抹掉,明天的数目大致一估;把一笔钱分给几个人,他除一下、报个大概数,剩下的零头懒得管,就让它不明不白地没了;同样一笔账,他这次这么算、下次那么算,自己也没个准谱。平日里看着倒也顺,可一到月底盘点,账面上的数,和钱箱里实实在在的钱,就是对不上——差的可能就几分几角,但他翻遍了整本账,也说不清这点钱是哪儿来的、哪儿去的。而一个严谨的账房怎么记账?他认死理:每一分钱都得有出处、有去处;算分账,除不尽的零头他明明白白地写清楚补给谁,绝不让它悬空(这就是分摊的余数兜底);记账的规矩他从头到尾就一套,几时进位、几时舍去,雷打不动(这就是统一的显式舍入);本地的钱和外路的银钱,他分门别类、绝不混作一处(这就是币种隔离)。到了月底,他的账面和钱箱,分毫不差。同样是管一本账,马虎的账房被那些查不清的零头追着跑,严谨的账房让每一分钱都待在它该在的地方——差别不在"算术本身难不难",只在账房心里有没有"钱这种东西,是必须分毫不差的"这根弦。
最后想说,金额计算做没做对,差距永远不会在"本地开发、自己造几笔测试数据"时暴露——本地你造的流水,数量少、数额又"整",浮点误差小到根本冒不出头,你那行 balance += amount 加出来的数看着分毫不差,你自然觉得"金额嘛,用 float 存"一点问题都没有。它只在真实的、记着成千上万笔流水、每天都要对账的生产环境里才显形。那时候它会用最难堪的方式给你结账:做不好,你会因为 float 误差累积,在对账单上对着一笔查不出来源的钱熬上三天,会因为分摊不兜底,让一分钱凭空消失、账再也平不了,会因为舍入规则不统一,让同一笔钱在系统里有两张面孔;而做对了,你的每一笔金额从进入系统起就是精确的整数或 Decimal,每一次加减都分毫不差,每一次分摊都严丝合缝地拼得回总额,每天的账都平得干干净净。所以别等"一次对账差钱、几个人查上三天"那一刻找上门,在你写下每一个存金额、算金额的变量时就该想清楚:这个金额是用 float 存的吗、运算会不会累积误差、分摊的余数有没有人兜、序列化和入库会不会丢精度,这一道道精确的关口,我是不是都替这本账守住了?这些问题有了答案,你交付的才不只是一套"本地测着对"的代码,而是一本记着千万笔流水、天天对账分毫不差、让人放心的账。
—— 别看了 · 2026