JavaScript Number 类型因 IEEE 754 限制，安全整数上限为 9007199254740991，超限将精度丢失；应依场景选用 BigInt（纯整数）、字符串（展示/传输）或 decimal.js 等库（小数/混合运算），并推动前后端协同规避前端处理。
JavaScript 的 Number 类型无法安全表示超过 9007199254740991（即 Number.MAX_SAFE_INTEGER）的整数，超出后会出现精度丢失——比如 9007199254740992 === 9007199254740993 返回 true。这不是 bug，而是 IEEE 754 双精度浮点数的固有局限（52 位尾数决定精度上限）。真正需要精确处理极大整数时，不能依赖 Number，而应选用更合适的替代方案。
用 BigInt 处理任意精度整数
BigInt 是原生、轻量、专为大整数设计的解决方案，适用于 ID 运算、密码学、高精度计数等纯整数场景：
- 创建必须用字面量加
n（如123456789012345678901234567890n）或字符串入参的BigInt("...")；避免传入已失真的 Number（如BigInt(9007199254740992)会出错） - 支持
+、-、*、**、%和所有位运算，但/向零截断（7n / 2n === 3n），不保留小数 - 不可与 Number 混合运算：
5n + 3直接报TypeError；需显式转换，如5n + BigInt(3) - 比较推荐用
===（类型严格），==虽能跨类型比较（5n == 5为true），但易掩盖类型误用 - JSON 不支持 BigInt，序列化前需转字符串：
JSON.stringify(big, (k, v) => typeof v === 'bigint' ? v.toString() : v)
用字符串暂存或传输超大整数
当只需展示、校验或中转（如 API 请求/响应），无需前端计算时，字符串是最简单、最安全的选择：
- 后端应将长 ID、雪花 ID、高精度时间戳等字段统一以字符串形式返回，避免 JSON 自动解析成 Number 导致截断
- 前端可直接使用字符串做相等判断、拼接、格式化（如每 4 位加空格），或仅在必要时转为 BigInt 处理
- 优势是零兼容成本、无精度风险、无运行时开销；缺点是无法直接参与数学运算
用专用库支持浮点与混合运算需求
当业务涉及小数、四则精度要求高（如金融分单位计算）、或需与 Number 无缝协作时，第三方库更合适：
立即学习“Java免费学习笔记（深入）”；
-
decimal.js：专注十进制浮点运算，支持任意精度小数，适合金额、汇率、科学数据 -
bignumber.js：API 类似decimal.js，兼容性更广，对旧环境友好 -
big-integer：轻量整数库，提供阶乘、模幂等密码学常用方法 - 注意：这些库本质是对象封装，性能低于原生 BigInt；引入前应评估是否真需其能力，而非仅因“看起来更强大”
前后端协同降低前端负担
很多大整数问题其实不该由前端承担：
- ID 类字段（如 MongoDB ObjectId、Snowflake）建议后端生成并全程以字符串透出，前端只做渲染和透传
- 复杂运算（如大数签名验证、余额汇总）尽量放在服务端，前端仅触发请求并展示结果
- 若必须前端处理，优先约定接口协议：所有大整数字段加
_str后缀或统一放在data_raw中，避免歧义
