javascript中number类型能精确表示的整数上限为9007199254740991（即2⁵³−1），下限为−9007199254740991；超出后因ieee 754双精度浮点数53位有效精度限制，加减1可能无效、相等判断出错，需用number.issafeinteger()校验或改用bigint、字符串处理。
JavaScript 的 Number 类型能**精确表示的整数上限是 9007199254740991（即 2⁵³ − 1）**，下限是 −9007199254740991。超出这个范围的整数就不再“安全”——加减 1 可能无效，相等判断可能出错，且这种失真不会报错，而是静默发生。
什么是“安全整数”
安全整数指在 IEEE 754 双精度浮点格式下，能被唯一、无损表示和运算的整数。它不是“能存下的最大数”，而是“能可靠计算的最大整数”。关键原因在于 Number 的 64 位结构中，只有 53 位用于有效数字（含隐含前导 1），因此连续可表示的整数只能到 2⁵³ − 1。
- 9007199254740991 + 1 === 9007199254740992 → true（正确）
- 9007199254740992 + 1 === 9007199254740992 → true（已失真，+1 没效果）
- Number.isSafeInteger(9007199254740992) → false
哪些场景容易踩坑
很多业务数据天然超出安全整数范围，但开发者常误以为“还是整数，应该没问题”：
- 后端返回的雪花 ID（如 53568055673880576）、订单号、区块链地址
- 高精度时间戳（毫秒级时间戳在 2038 年后将超限；微秒级/纳秒级几乎必然超限）
- 大额金融计数（如账户余额达千亿级别时，以分为单位也可能逼近上限）
- JSON 自动解析：接口返回
{"id": 9007199254740992}，JS 解析后值已变，Network 面板显示原始字符串是对的，Preview 里却是错的
如何检测和规避
不能靠肉眼判断，必须用机制兜底：
- 用
Number.isSafeInteger(n)做运行时校验，尤其对 ID、序列号等关键字段 - 后端应将超大整数字段统一定义为字符串类型（JSON 中写成
"id": "9007199254740992"），前端直接当字符串使用 - 若需运算，用
BigInt：必须以n结尾（如9007199254740992n），或用BigInt("9007199254740992")构造；注意不能与 Number 混合运算 - 避免用
parseInt或Number()转换超大字符串，它们会先转成 Number 再截断；应直接走 BigInt 或保留字符串
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
