Number.isSafeInteger用于判断值是否为安全整数，即类型为number、是整数且在[-2⁵³+1, 2⁵³−1]范围内可精确表示，不进行类型转换，对非数字、小数、NaN等均返回false。
Number.isSafeInteger 不是用来“检测越界”的工具，它只回答一个问题：这个值是不是一个安全整数？不是“超没超”，而是“当前这个值本身是否可信赖”。后端传来的 ID、版本号、时间戳（毫秒级）等字段一旦超出 Number.MAX_SAFE_INTEGER（即 9007199254740991），JavaScript 就无法保证其精确相等和运算一致性——Number.isSafeInteger 是你第一时间能用的、最轻量的守门员。
为什么不能直接用 Number.isSafeInteger 判断“是否越界”
它不返回差值、不抛错、也不告诉你“超了多少”。比如：
Number.isSafeInteger(9007199254740992) // false
Number.isSafeInteger(9007199254740991) // true
Number.isSafeInteger("9007199254740992") // false（字符串，类型不对）
Number.isSafeInteger(NaN) // false
Number.isSafeInteger(123.45) // false（不是整数）
也就是说，只要结果是 false，你得进一步排查原因：是类型错了？是小数？还是真越界了？它不区分这些情况。
后端字段校验的典型错误链路
- 后端返回 JSON 中的
"id": 9007199254740992→ 前端解析为9007199254740992，但此时该数字在 JS 内部已不可靠（9007199254740992 === 9007199254740993可能为true） - 前端用
parseInt或+强转字符串 ID：+"9007199254740992"→ 得到同样失真的数字 - 用
Number.isSafeInteger(id)检查 →false，但你不知道是因为后端传了字符串，还是真超了，还是中间被某层 JSON 库自动转成了 number
真正可用的校验组合策略
单靠 Number.isSafeInteger 不够，要配合类型和来源判断：
- 先确认字段是
number类型：typeof id === 'number' && isFinite(id)，排除NaN和Infinity - 再用
Number.isSafeInteger(id)—— 这步才真正过滤掉精度风险 - 如果字段本应是字符串（如后端明确要求 ID 以字符串传输），那就跳过
Number.isSafeInteger，直接走字符串校验逻辑（比如正则/^\d+$/+ 长度限制） - 对高风险字段（如金融金额、加密 nonce、分布式 ID），默认禁用
number类型接收，强制要求后端用字符串传，并在前端用BigInt或保留字符串做比对
容易被忽略的边界点
很多人以为只要 id 就安全，但忘了：加减运算也会立刻打破安全边界。例如：
const a = Number.MAX_SAFE_INTEGER; // 9007199254740991 const b = 1; Number.isSafeInteger(a + b); // false —— 即使 a 和 b 单独都安全，a + b 已不可信
所以，Number.isSafeInteger 只适合做「静态值快照校验」，不适合嵌入计算流程。涉及累加、分页偏移、序列生成等逻辑，必须从设计上规避 number 类型参与长周期状态维护。
