javascript中能精确表示、可靠运算的整数范围是-9007199254740991至9007199254740991，超出后因ieee 754双精度浮点数53位有效精度限制，导致加减1无效、相等判断出错，需用number.issafeinteger()校验或改用bigint、字符串处理。
JavaScript 中能精确表示、可靠运算的整数，上限是 9007199254740991，下限是 -9007199254740991。超出这个范围，整数就不再“安全”——加减 1 可能无效，相等判断可能出错，后端传来的 ID 或时间戳若超限，容易引发静默错误。
什么是“安全整数”
安全整数指在 IEEE 754 双精度浮点格式下，能被**唯一、无损表示**的整数。Number 类型用 64 位存储，其中 53 位用于有效数字（含隐含位），因此最大可精确表示的整数是 2⁵³ − 1。
- 它不是“能存下的最大数”，而是“能精确计算的最大整数”
- 超过后，相邻两个可表示的数之间间隔大于 1，比如
9007199254740992和9007199254740993在 JS 中可能被存为同一个值 -
Number.isSafeInteger(n)是检测它的标准方法，返回布尔值
关键常量与实际值
JS 提供了两个只读常量，直接对应这个边界：
Number.MAX_SAFE_INTEGER === 9007199254740991Number.MIN_SAFE_INTEGER === -9007199254740991
注意：这两个值和 Number.MAX_VALUE（≈1.798e+308）或 Number.MIN_VALUE（≈5e−324）完全无关——后者描述的是浮点数表示范围，不是整数精度保障范围。
超出安全范围的典型问题
常见于大 ID、高精度时间戳、金融计算或科学数据处理：
-
9007199254740991 + 1 === 9007199254740992✅ 正确 -
9007199254740992 + 1 === 9007199254740992❌ 精度丢失，结果没变 - 后端返回的 19 位订单号（如
1234567890123456789）可能被 JS 读作1234567890123456800
如何应对超限场景
不能靠四舍五入或字符串转换来“修复”精度，而应从类型和设计层面规避：
- 传输大整数时，优先用字符串（如 JSON 中的
"id": "1234567890123456789"），再按需解析 - 需要计算时，使用
BigInt（如BigInt("1234567890123456789") + 1n），但注意它不能和普通 number 混用 - 校验逻辑中主动调用
Number.isSafeInteger()，尤其在接收 API 数据或用户输入后 - 避免用
==或===直接比较可能超限的整数，必要时转字符串比对
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
