Number.isSafeInteger 仅当参数为整数且在 [-(2^53-1), 2^53-1] 内才返回 true；它不判断“是否超出”，而是先验整数性，再验范围，对非精确整数（如 2^53）、NaN、Infinity、小数、字符串均返回 false。
Number.isSafeInteger 为什么不能直接判断“是否超出安全范围”
Number.isSafeInteger 只会返回 true 当且仅当传入值是整数，且在 -(2^53 - 1) 到 2^53 - 1 之间（含端点）。它不关心你“想判断什么”，只做两件事：检查是否为整数、再检查是否落在安全区间内。
常见误解是拿它来检测一个大数“是不是已经不安全了”，比如：Number.isSafeInteger(9007199254740992 + 1) → 返回 false，但原因不是“超出了”，而是 9007199254740992 + 1 在 JS 中根本无法精确表示为整数（它等于 9007199254740992），所以连“整数”这关都没过。
- 它对
NaN、Infinity、小数、字符串数字（如"123"）一律返回false - 它对
2**53（即9007199254740992）返回false，因为这不是安全整数——安全上限是2**53 - 1 - 它对
Math.pow(2, 53) - 1返回true，这才是边界验证的正确用法
怎么真正验证一个数是否“在安全整数范围内”
如果你有一个数值 val，想确认它没被精度吞噬、能被 JS 安全参与计算（比如作为数组索引、ID、计数器），应该分两步：
- 先确保它是数字类型且不是
NaN或Infinity：typeof val === 'number' && isFinite(val) - 再用
Number.isSafeInteger(val)—— 这一步才真正校验范围和整数性
合并写法示例：
立即学习“Java免费学习笔记（深入）”；
function isInSafeIntegerRange(val) {
return typeof val === 'number' && isFinite(val) && Number.isSafeInteger(val);
}
<p>isInSafeIntegerRange(9007199254740991); // true
isInSafeIntegerRange(9007199254740992); // false（已越界）
isInSafeIntegerRange(12.5); // false（非整数）
isInSafeIntegerRange('123'); // false（非 number 类型）
为什么 parseInt / parseFloat 后不能直接丢给 Number.isSafeInteger
字符串转数字容易引入隐式转换陷阱。比如：parseInt('123.456') → 123（看起来没问题），但 parseInt('0x10') → 16，而 parseInt('1e2') → 1（因为默认按十进制解析，遇到 e 就停了）。
- 用
Number()比parseInt更可靠：它能正确处理科学计数法、十六进制（带0x前缀）、空格等 - 但
Number('1e2')→100，是浮点数，Number.isSafeInteger(100)→true；而Number('1e100')→Infinity，Number.isSafeInteger(Infinity)→false - 关键点：必须先确认
Number(str)的结果是有限数字，再交给Number.isSafeInteger
后端传来的 ID 或时间戳要特别小心
很多后端用 64 位整数（如 Java 的 long、PostgreSQL 的 BIGINT），JS 无法安全表示大于 2^53 - 1 的整数。即使接口返回的是 JSON 数字，一旦超过安全范围，前端解析后就可能失真。
- 例如：
9223372036854775807（int64 最大值）→ JS 中变成9223372036854776000（末几位归零） -
Number.isSafeInteger对它返回false，但这只是“症状”，不是“诊断”——你得提前知道这个 ID 本不该被当数字处理 - 最佳实践：对可能超界的 ID、时间戳（尤其是毫秒级 Unix 时间戳，2038 年后部分系统会超界），统一用字符串传输，并在前端始终以
string类型存储和传递
安全整数范围不是性能瓶颈，而是精度契约。一旦打破，错误不会报错，只会悄悄吃掉数字末尾——这才是最难 debug 的地方。
