BigInt是专为超大整数精度运算设计的原始类型，需用字符串或字面量（如"123n"）初始化，禁混用Number、不支持JSON，适用于ID、密码学等场景。
JavaScript 中 BigInt 是专为解决数值溢出和精度丢失而设计的原始类型，它不替代 Number，而是补足其在超大整数场景下的短板。关键在于：只在真正需要精确整数运算时启用，且必须规避与 Number 混用、JSON 序列化、Math API 调用等常见陷阱。
识别溢出风险的典型场景
当数值超过 Number.MAX_SAFE_INTEGER（9007199254740991） 时，Number 类型就无法保证整数精度。这类场景包括：
- 后端返回的 64 位 ID（如 Snowflake、数据库主键、区块链交易哈希）
- 文件大小（尤其 TB 级以上）、时间戳（毫秒级长周期）、计数器（高频累加）
- 密码学运算（模幂、大质数生成）、天文或科学计算中的整数建模
- 前端解析 JSON 时，若 ID 字段被自动转为 Number，哪怕只是比较或展示，也可能悄然失真
正确创建和初始化 BigInt
避免因初始化方式不当引入首次精度损失：
- 永远不要用
BigInt(12345678901234567890123)—— 这个数字在传入前已被 Number 解析截断 - 优先使用字符串入参：
BigInt("12345678901234567890123") - 字面量写法更安全：
12345678901234567890123n（注意末尾 n 不可省略） - 从已有 BigInt 或小整数转换时，确保来源可靠：
BigInt(safeNum)仅限 ≤ MAX_SAFE_INTEGER 的值
运算与交互中的安全实践
BigInt 不是“增强版 Number”，它的行为有明确边界：
立即学习“Java免费学习笔记（深入）”；
- 禁止混合运算：
5n + 3直接报错；需显式转换，如5n + BigInt(3)或Number(5n) + 3（后者仅当确认值在安全范围内） - / 运算向零截断：
7n / 2n === 3n（不是 3.5），取模%保持整数语义 - 比较用
===判断相等性（类型严格），==允许跨类型但易引发混淆，不推荐 - JSON 不支持：
JSON.stringify({id: 123n})抛错；应提前转字符串：{id: bigId.toString()}或自定义 replacer
前后端协同与性能权衡
BigInt 解决的是精度问题，不是万能性能方案：
- 传输层统一约定：后端返回大 ID 一律为字符串字段（如
"id": "12345678901234567890"），前端再转 BigInt - 序列化输出时，始终转回字符串供接口消费或 DOM 渲染，避免下游系统不兼容
- 性能敏感路径（如高频循环、动画帧内计算）慎用 BigInt；百位以上数字的乘除/幂运算耗时可能是 Number 的 5–10 倍
- 旧环境兼容：Node.js ≥10.4、Chrome ≥67、Firefox ≥68、Safari ≥14 支持；不支持时可用字符串暂存+逻辑降级
