BigInt适用于超大整数运算，如雪花ID、密码学、金融分账和纳秒级时间差；须用字符串初始化，避免Number解析污染；禁止与Number混合运算，需显式转换并确保安全。
用 BigInt 处理高精度整数，关键不在“全盘替换 Number”，而在于精准识别适用场景 + 控制类型边界 + 避免隐式转换。它本身不解决浮点问题，也不适合高频小数值计算；但对超大整数运算，它是唯一原生、安全、低开销的方案。
只在真正需要大整数语义时才创建 BigInt
多数前端场景（如 UI 计数器、表单输入、时间差）完全不需要 BigInt。滥用会增加内存占用和 GC 压力。重点用于：
- 解析后端返回的 19 位雪花 ID（如
"1724859301284761600"）并做数值比较或偏移计算 - 密码学相关运算（如模幂、大素数验证）
- 金融系统中纯整数金额的累计、分账（单位为“分”，避免小数）
- 高精度时间戳差值计算（如纳秒级日志时间差）
初始化必须用字符串，绕过 Number 解析污染
直接传数字字面量或 Number 类型进 BigInt()，可能已在前一步丢失精度：
- ❌
BigInt(1724859301284761600)→ 先被 JS 当作 Number 解析，末尾已变 00 - ✅
BigInt("1724859301284761600")→ 字符串无精度损失，安全构造 - ✅
const id = "1724859301284761600"; const bigId = BigInt(id);
推荐在响应拦截器中统一处理：用 json-bigint 配置 storeAsString: true，让所有超长数字字段一进入 JS 就是字符串，后续按需转 BigInt。
运算全程保持类型纯净，杜绝混合操作
BigInt 与 Number 混合运算会立即报错（如 5n + 3），这不是 bug，而是设计保护。正确做法是：
- 加减乘除取模幂：所有操作数都为 BigInt，例如
bigA * bigB、bigN % 1000n - 需要跨类型交互时，显式转换且确认安全：
– 转 Number：仅当bigN 时可用 <code>Number(bigN)
– 转字符串：通用安全出口，bigN.toString()可用于展示、拼接 URL、存 localStorage - 避免在循环内反复调用
BigInt(str)；可提前缓存常量，如const ONE_MILLION = 1_000_000n;
序列化与通信要手动适配，不能依赖默认 JSON
BigInt 不可被 JSON.stringify() 序列化，否则抛错。必须主动处理：
- 发送请求前：将 BigInt 字段转字符串（
order.id.toString()），确保后端能接收（若后端要求 JSON 数字，需服务端配合改用字符串接收） - 本地存储：用
localStorage.setItem("lastId", bigId.toString()) - 自定义序列化函数示例：
JSON.stringify(obj, (k, v) => typeof v === "bigint" ? v.toString() : v)
反序列化时再按需转回：JSON.parse(jsonStr, (k, v) => /^\d+$/.test(v) && v.length > 15 ? BigInt(v) : v)（注意判断逻辑需贴合业务字段特征）
