number.issafeinteger用于判断数值是否为安全整数（±9007199254740991内可精确表示），专用于id、金额等大数精度兜底，非通用整数校验，对非数字类型一律返回false。
Number.isSafeInteger 主要用于判断一个数值是否为“安全整数”，即在 JavaScript 的 IEEE 754 双精度浮点数表示范围内，能被**精确表示且不丢失精度**的整数（范围是 -(2<sup>53</sup> - 1) 到 2<sup>53</sup> - 1，即 ±9007199254740991）。它不是通用的“是否为整数”校验工具，而是一个**精度保障型检查**，在业务中真正有用的地方，往往出现在对 ID、计数、金额、序列号等关键数值做可靠性兜底时。
校验后端返回的 ID 或序列号是否可能出错
很多系统使用 64 位整数 ID（如 Snowflake、数据库自增 bigint），但 JSON 本身不区分 int/float，JavaScript 会将其转为 Number 类型。一旦 ID 超出 2<sup>53</sup> - 1，就可能被四舍五入，导致 ID 失真（例如 9007199254740992 和 9007199254740993 在 JS 中相等）。这时用 Number.isSafeInteger(id) 可快速识别风险：
- 若返回
false，说明该 ID 在 JS 中无法精确表达，应改用字符串传输并处理（如后端返回"id": "9007199254740992"） - 前端收到数字 ID 后，建议立即校验：
if (!Number.isSafeInteger(id)) console.warn('ID 精度可能丢失') - 注意：它只判数字类型，
Number.isSafeInteger("123")直接返回false，无需额外typeof判断
防止大数运算结果意外失真
当业务涉及金额累计、库存计数、分页总数等可能增长到极大值的场景，运算结果若超出安全整数范围，后续比较或存储就会出错。例如：
- 用户总充值额 = 上次总额 + 本次金额，若总额已接近
2<sup>53</sup>，再加 1 可能无变化 - 分页接口返回
total: 9007199254740992，前端计算总页数Math.ceil(total / pageSize)会得到错误结果 - 可在关键累加后插入校验：
if (!Number.isSafeInteger(newTotal)) throw new Error('累计值溢出，需切换为 BigInt 或字符串处理')
与 parseInt/Number 区分使用，避免误判
很多人误以为 Number.isSafeInteger 可替代类型校验，但它对非数字输入一律返回 false，且不处理字符串转换。常见误区：
-
Number.isSafeInteger("123")→false（不是数字类型） -
Number.isSafeInteger(123.0)→true（.0 不影响，仍是整数且安全） -
Number.isSafeInteger(123.5)→false（不是整数） - 需要先转类型再校验？通常不需要——业务中应确保传入的是 number；若来源不可控，先用
Number(val)转换，再用isSafeInteger，但要注意Number("abc")是NaN，而Number.isSafeInteger(NaN)也是false
不适用于常规表单整数校验
用户输入的年龄、数量等小范围整数，用 Number.isInteger 或正则 /^-?\d+$/ 更合适。isSafeInteger 在这里属于“过度防护”：
- 年龄不可能超过 1000，远小于安全上限，用它毫无必要
- 它无法捕获字符串格式错误（如空格、字母），也不处理边界业务逻辑（如年龄不能为负）
- 真正需要它的场景，往往已隐含“这个数可能很大”的前提，比如处理分布式 ID、日志序号、大数据量统计结果
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
