JS数字货币转换精度总丢，0.1+0.2不等于0.3怎么解

导读： JS数字货币转换精度总丢，0.1+0.2不等于0.3怎么解做前端支付和钱包功能这几年，JS里金额和数字货币的精度问题我反复踩坑。数字货币更夸张，BTC有8位小数精度，ETH有18位，直接拿浮点数做加减乘除，误差会随交易笔数线性累积。BTC按当前市价卖出，先乘汇率再减手续费，中间每一步都在丢精度。...

JS数字货币转换精度总丢，0.1+0.2不等于0.3怎么解

做前端支付和钱包功能这几年，JS里金额和数字货币的精度问题我反复踩坑。浮点运算看似简单JS数字货币转换问题JS数字货币转换精度总丢，0.1+0.2不等于0.3怎么解，一到了真实交易场景，误差就会以各种方式冒出来，让人抓狂。

根本原因在IEEE 754：JS的Number用64位双精度浮点，二进制天然无法精确表示0.1、0.2这样的十进制小数。0.1+0.2的结果是0.30000000000000004。数字货币更夸张，BTC有8位小数精度，ETH有18位，直接拿浮点数做加减乘除，误差会随交易笔数线性累积。

实际业务里最疼的场景是汇率换算和手续费计算。比如用户0.005 BTC按当前市价卖出，先乘汇率再减手续费，中间每一步都在丢精度。用toFixed(2)展示虽然看着正常，但底层值已经偏了，连续累加一百笔后偏差可能超过一个聪，对账时直接炸。

工程上的解法就几条：把金额统一放大成最小单位的整数（BTC用satoshi，人民币用分），全程整数运算；涉及大数用BigInt；或者引入decimal.js把精度交给库。核心原则是精度控制要前置到数据模型层，别指望渲染阶段四舍五入能兜底。

说白了，JS不是不能处理金钱，是你得在架构设计时就把它当整数问题来做。等出了bug再补patch，永远不如一开始就选对工具。