BigInt处理高精度数值：避免精度丢失与性能损耗

在处理高精度整数时，BigInt 的价值并非要取代 Number，而在于精准识别适用场景、严格控制类型边界、并彻底避免隐式转换。它本身不解决浮点数精度问题，也不适合高频的小数值计算；但对于那些真正需要处理超大整数的场景，它提供了唯一原生、安全且开销可控的方案。

BigInt 核心应用场景

绝大多数前端场景，比如 UI 计数器、表单输入、常规时间差计算，完全用不到 BigInt。滥用它只会徒增内存占用和垃圾回收的压力。它的核心应用场景非常明确：

• 解析后端返回的超长数字，例如 19 位的雪花 ID（如 "1724859301284761600"），并进行数值比较或偏移计算。
• 密码学相关运算，例如模幂运算或大素数验证。
• 金融系统中以“分”为单位的纯整数金额累计、分账，从而彻底规避小数精度问题。
• 需要纳秒级精度的时间戳差值计算，例如性能日志分析。

BigInt 初始化方法

直接将数字字面量或 Number 类型的值传入 BigInt() 构造函数是危险的，因为它在被 BigInt 处理前，可能已经作为 Number 丢失了精度：

• BigInt(1724859301284761600) → 这个数字会先被 JavaScript 引擎当作 Number 解析，末尾几位很可能已经变成了 00。
• BigInt("1724859301284761600") → 字符串表示能完整保留所有位数，安全构造。
• const id = "1724859301284761600"; const bigId = BigInt(id);

一个推荐的做法是在网络响应拦截器中统一处理。例如，使用 json-bigint 库并配置 storeAsString: true，让所有超过 JavaScript 安全整数范围的数字字段，在进入代码时就是字符串格式，后续再按需转换为 BigInt。

BigInt 运算规则

BigInt 与 Number 进行混合运算会立即抛出错误（例如 5n + 3），这并非缺陷，而是语言设计上的保护机制。正确的做法是：

• 进行加减乘除、取模、幂运算时，确保所有操作数都是 BigInt 类型，例如 bigA * bigB、bigN % 1000n。
• 当需要与 Number 类型交互时，必须进行显式转换，并确保转换安全：
  – 转为 Number：仅在确认 bigN 时可用 Number(bigN)。
– 转为字符串：这是最通用、最安全的出口，bigN.toString() 的结果可用于展示、拼接 URL 或存入 localStorage。
• 避免在循环内部反复调用 BigInt(str) 进行构造；可以提前缓存常量，例如 const ONE_MILLION = 1_000_000n;。

BigInt 序列化与通信

BigInt 类型无法被 JSON.stringify() 直接序列化，否则会抛出错误。因此，必须主动处理：

• 发送请求前：将对象中的 BigInt 字段转换为字符串（例如 order.id.toString()），并确保后端接口能够接收字符串形式的数字（如果后端要求 JSON 数字格式，则需要服务端配合调整接收逻辑）。
• 本地存储：使用 localStorage.setItem("lastId", bigId.toString())。
• 可以自定义序列化函数，例如：
  JSON.stringify(obj, (k, v) => typeof v === "bigint" v.toString() : v)

反序列化时，再根据业务字段的特征判断并转回 BigInt：JSON.parse(jsonStr, (k, v) => /^\d+$/.test(v) && v.length > 15 BigInt(v) : v)。这里的判断逻辑（如长度大于15）需要根据实际业务数据的特征进行调整。