BigInt精准计算代币余额技巧

区块链代币余额的精准计算绝非简单除法，而是贯穿前后端全链路的精度保卫战：由于BigInt仅支持整数运算，直接用`/`进行小数缩放必然丢失精度，正确做法是全程规避Number类型——前端须将原始整数余额（如wei）作为字符串处理，通过字符串操作手动插入小数点实现无损格式化；后端必须以字符串接收并借助BCMath等高精度库完成缩放；从JSON解析、API传输、数据库存储到最终展示，任一环节误用Number都会导致不可逆的精度坍塌，尤其在高精度代币或大额场景下可能引发数量级错误。

直接用 BigInt 做除法会报错，必须先转成字符串再用 bcdiv 或手动缩放；JavaScript 中无法用 / 运算符对 BigInt 执行小数缩放，这是最常踩的坑。

BigInt 不能直接除以 10ⁿ 得到带小数的余额

区块链原始余额（如 wei、atom）总是整数，但展示时需按 decimals 缩放。例如 USDC 的 decimals = 6，余额 12345678n 应显示为 12.345678。但 12345678n / 10n**6n 会截断小数——结果是 12n，不是你要的浮点格式。

• 根本原因：BigInt 只支持整数除法（divmod 行为），不支持小数结果
• 错误写法：balance / 10n**decimals → 永远丢小数位
• 正确路径：先转字符串，再用 Number() 或 parseFloat() 构造可读值，或交给后端用 BCMath 处理
• 若需保留全部小数位（如审计用途），建议保持 BigInt + decimals 二元组存储，仅在展示层格式化

前端展示时如何安全生成 35.675 这样的字符串（不带冗余零）

用 Number() 转换有风险：超过 Number.MAX_SAFE_INTEGER（9007199254740991）的 BigInt 转成 Number 会丢失精度。所以不能无脑 Number(balance) / Math.pow(10, decimals)。

• 安全做法：将 BigInt 转为字符串，手动插入小数点
• 示例：const s = balance.toString(); const padded = s.padStart(decimals + 1, '0'); const dotIndex = Math.max(0, padded.length - decimals); const human = `${padded.slice(0, dotIndex)}.${padded.slice(dotIndex)}`.replace(/^0+(?=\d)/, '')
• 更简方案：用 Intl.NumberFormat 配合 minimumFractionDigits 和 maximumFractionDigits，但前提是已用字符串+小数位构造出精确十进制值
• 注意：不要用 toFixed()，它底层调用 Number，仍会触发精度截断

为什么不能把 rawBalance 当 Number 传给后端做缩放

Node.js 中若用 Number 接收一个 64 位以上整数（如 BSC 上某笔交易的 value 字段），解析 JSON 时就已失真——JSON.parse('{ "value": "12345678901234567890123" }') 是安全的，但 JSON.parse('{ "value": 12345678901234567890123 }') 会变成 12345678901234567000000。

• 后端收到的已经是错误值，再怎么用 bcdiv 都无法还原
• 正确链路：前端始终以字符串传 rawBalance，后端用 bcdiv((string)$rawBalance, bcpow('10', (string)$decimals, 0), $decimals)
• 若后端是 Node.js 18+，可用 BigInt(rawBalanceStr) + 手动字符串拼接小数点，避免任何 Number 中间态
• 硬编码 decimals 比动态读取合约更危险——DAI 和 USDC 都是 ERC-20，但精度不同，混用会导致 10⁶ 倍误差

真正难的不是“怎么算”，而是确保整条链路上每个环节都拒绝 Number 类型介入：从 RPC 返回的 JSON 解析、中间服务转发、数据库字段类型（别用 BIGINT 存 wei，要用 TEXT 或 DECIMAL(78,0)），到最终展示——只要有一环松动，精度就归零。

理论要掌握，实操不能落！以上关于《BigInt精准计算代币余额技巧》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！