JavaScript中Number类型安全整数范围为±9007199254740991，超出易精度丢失；BigInt提供任意精度整数支持，适用于大订单号、Snowflake ID、定时器ID、Web Worker通信、IndexedDB键等异步场景，需字符串构造、同类型比较、转字符串序列化，并注意兼容性与性能限制。
JavaScript 中的 Number 类型基于 IEEE 754 双精度浮点数，安全整数范围仅限于 -(2<sup>53</sup> - 1) 到 2<sup>53</sup> - 1（即 ±9007199254740991）。超出该范围的整数在运算或异步传递（如 API 响应、定时器 ID、WebSocket 消息、IndexedDB 存储）中极易发生精度丢失——例如 9007199254740993 === 9007199254740992 返回 true。而 BigInt 提供任意精度整数支持，是规避此类异步逻辑 Bug 的关键工具。
识别需要 BigInt 的异步场景
以下情况一旦涉及大整数，就应优先考虑 BigInt：
- 后端返回的超长订单号、分布式 ID（如 Snowflake ID，常为 64 位整数）
-
setTimeout/setInterval返回的定时器 ID（在长时间运行或高并发下可能超出Number.MAX_SAFE_INTEGER） - Web Worker 或跨 iframe 通信中传递的计数器、偏移量、时间戳（毫秒级时间戳在 2255 年后将超过
2<sup>53</sup>） - IndexedDB 中存储/检索的大整数键（如用
BigInt作主键或索引）
正确声明与转换 BigInt
不能混用 Number 和 BigInt 进行算术或比较（会直接抛错），需显式转换：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 字面量写法：
123n或BigInt("123")（推荐字符串构造，避免Number先丢失精度） - 禁止：
BigInt(9007199254740993)—— 因传入的Number已失真；应写BigInt("9007199254740993") - 比较必须同类型：
123n === BigInt(123)✅，但123n === 123❌（返回false，且严格相等不隐式转换） - JSON 不支持
BigInt，序列化前需转字符串：JSON.stringify({ id: id.toString() })
在异步链路中保持 BigInt 一致性
从接收、处理到传出，全程维持类型纯净：
立即学习“Java免费学习笔记（深入）”；
- API 响应解析时立即转
BigInt：fetch("/order").then(r => r.json()).then(data => ({ ...data, id: BigInt(data.id) })) - Worker 通信使用
postMessage时，可直接传输BigInt（需开启transferable支持，现代浏览器已默认支持） - 避免在 Promise 链中意外降级：
Promise.resolve(BigInt("1000")).then(x => x + 1n).then(console.log) // ✅<br>Promis.resolve(BigInt("1000")).then(x => x + 1).catch(console.error) // ❌ TypeError
注意兼容性与边界限制
BigInt 并非万能，需结合运行环境谨慎使用：
- IE 完全不支持；Node.js ≥ 10.4（需启用
--harmony-bigint），现代 Chrome/Firefox/Safari 均已默认支持 - 不能用于
Math方法（如Math.pow）、日期计算（new Date(ms)参数仍需Number） - 与
float运算不兼容，若需混合计算（如比例、除法），应明确取整策略并转回Number（注意此时可能再次丢失精度） - 大型
BigInt运算（如百位以上乘方）性能显著低于Number，高频异步任务中需压测验证
