做域名交易或者批量注册的时候，你有没有发现价格经常是像 12.99、8.50 这样的数字？这些金额看着不起眼，但系统处理时如果用浮点数来算，可能就会出问题。比如买 10 个 8.99 元的域名，本该是 89.9 元，结果系统算出来是 89.8999999。这可不是吓唬人，而是浮点数精度缺陷的真实写照。
浮点数为啥不靠谱？
计算机里的浮点数是用二进制表示的，像 0.1 这种十进制里很简单的数字，在二进制里其实是无限循环小数。这就导致计算时会出现微小误差。时间一长，误差累积，账对不上就麻烦了。
比如你在后台看到用户账户余额是 100.00，实际存的是 99.99999999999999，虽然显示正常，但做精确比对的时候，if (balance == 100.0) 就会返回 false，程序逻辑直接跑偏。
固定小数位怎么解决这个问题？
与其用 float 或 double 存金额，不如统一用“最小单位”来记账。比如所有价格都按“分”来存，10 元就是 1000 分。这样全是整数运算，完全避开浮点误差。
在数据库设计里，很多域名注册商都会把价格字段定义成 INT 类型，单位是“厘”或“分”，前端展示时再除以 100 或 1000 转成元。这样一来，加减乘除都不会出错。
\/\/ 存储时：价格 12.99 元 = 1299 分
int priceInCents = 1299;
\/\/ 计算总价：10 个域名
int total = priceInCents * 10; \/\/ 结果是 12990，精准无误
\/\/ 展示时转换
double displayPrice = total / 100.0; \/\/ 得到 129.90实际场景中的应用
你在阿里云、腾讯云买域名的时候，看到的价格都是两位小数。这些平台背后几乎都不会用 float 存金额。哪怕是临时计算折扣、满减活动，也会先把所有值转成分再算，最后再转回来展示。
有些小型服务商图省事，直接用 PHP 的 float 或 JavaScript 的 number 类型处理价格，结果对账时发现差了几毛钱，查半天才发现是浮点精度惹的祸。
固定小数位不只是技术选择，更是一种严谨的态度。尤其在涉及资金、批量数据、自动化计费的场景下，宁愿多写两行代码做单位转换，也不要把风险留给浮点数。