JS 精度陷阱？BigInt 才是大数处理的正解

做前端开发时，你一定遇到过这种离谱的场景：后端返回一个巨大的订单号或用户 ID，字符串看着挺正常，可一旦转成数字类型，最后几位莫名其妙变成了 000。更夸张的是，当你想拿两个大数做加减乘除，结果可能直接出错。这不是代码写错了，而是 JavaScript 原生 Number 类型的先天 limitation。

JS 里的数字本质上都是双精度浮点数，遵循 IEEE 754 标准。这意味着它能安全表示的最大整数只有 2^53 - 1（即 9007199254740991）。超过这个范围，精度就开始丢失。对于金融金额、雪花算法生成的 ID 或者区块链相关数据，这个上限根本不够用。以前大家只能妥协，要么用字符串存数字，要么引入第三方大数库，维护成本居高不下。

现在好了，ES2020 推出的 BigInt 类型彻底解决了这个问题。它允许你表示任意精度的整数，不再受 53 位限制。使用它非常简单，只要在数字后面加个后缀 n，或者调用全局函数 BigInt() 即可。比如定义一个大数：

const safeNum = 9007199254740991;
const bigIntVal = 9007199254740991n; 

看起来和普通数字没区别，但本质不同。关键点在于，BigInt 和 Number 不能混合运算。如果你尝试 bigIntVal + 1，浏览器会直接报错。你必须显式地将普通数字也转换成 BigInt，写成 1n 或 BigInt(1)。这就像两条平行的铁轨，不能随意交叉，强行混合只会导致程序崩溃。

除了运算规则，实际开发中还有几个容易踩的深坑。首先是类型判断。typeof 检查 bigint 类型会返回 'bigint'，而不是 'number'，这点在写通用工具函数时要格外留意。其次是布尔值比较。虽然 1n === 1 是 false，但 1n == 1 是 true，这里存在隐式转换的陷阱，建议始终严格比较，避免逻辑混乱。

最头疼的其实是 JSON 序列化。很多同事处理完数据后，直接调用 JSON.stringify()，结果发现大数对象被解析成了字符串格式，或者干脆报错。这是因为标准的 JSON 规范不支持 BigInt。要解决这个问题，你需要手写一个自定义的序列化函数，遍历对象将 BigInt 转为字符串：

function jsonReplacer(key, value) {
  if (typeof value === 'bigint') {
    return value.toString();
  }
  return value;
}
// 使用时传递 replacer 参数
JSON.stringify({ id: 123456789012345678n }, jsonReplacer);

反序列化的时候同理，接收到字符串后，再用 BigInt() 转回去。这样既保留了数据的准确性，又符合 JSON 协议。

当然，BigInt 也不是万能的。它的计算性能比原生 Number 略慢，且无法用于需要浮点数的场景。如果你的业务只是普通的界面数值展示，没必要强行上 BigInt；但涉及核心资金结算、长整型 ID 传输时，请务必把它纳入方案。技术选型没有银弹，只有最适合当下场景的工具。把合适的数据交给合适的类型，代码才能跑得更稳。