Number.MIN_SAFE_INTEGER是-9007199254740991，表示可精确运算的最小整数而非最小负数；用于ID校验等需精确判定的场景，超此范围易因浮点精度导致错误。
Number.MIN_SAFE_INTEGER不是“最小负数”，而是最小安全整数
直接用
当作“能表示的最小负数”是常见误解。它值为
，但这个数的意义不在于“多负”，而在于“还能精确参与运算”。比如
得到的是
，看似合理，但一旦参与比较、加减、JSON 序列化或跨系统传输，就可能因浮点精度丢失变成错误值（如
）。
所以它适合定义“业务上允许的最负 ID”“最低可信赖温度阈值”这类需要**精确判定和稳定计算**的边界，而不是“显示用的下限”。
在 ID/序列号校验中用 Number.MIN_SAFE_INTEGER 做安全下限检查
后端返回一个负 ID（比如订单取消后生成的补偿单 ID），前端要判断是否可信。不能只写
✅ 正确做法：用
—— 先保精度，再判符号
❌ 错误做法：仅靠
判断，漏掉
、
、小数、字符串等非法类型
⚠️ 注意：如果后端传的是字符串形式的负大数（如
），
或
转换后可能已失真，必须优先验证原始字符串长度或正则格式
与 Number.MIN_VALUE 混用会导致逻辑断裂
是
，是最小**正**浮点数，和整数安全完全无关。把它和
放一起做条件判断，等于拿温度计量体重。
典型错误场景：
真正该组合的是：
（全自动覆盖边界 + 类型 + 有限性）
或手动检查：
序列化和跨语言交互时，MIN_SAFE_INTEGER 边界会失效
JavaScript 的
是 JS 引擎内部对 IEEE 754 双精度浮点数的解释结果。但 Python、Java、PostgreSQL 等系统对“整数安全”的定义不同——有的支持任意精度整数，有的默认用 32 位有符号整型。
这意味着：
前端用
校验过的负 ID，传给 Java 后端可能被截断成
（int32 下限）
JSON 不区分整数/浮点数，大负整数序列化后可能被某些解析器当作浮点处理，悄悄丢精度
真正可靠的方案是：协议层约定字段为字符串（如
），由各端自行解析并校验
边界值本身很明确，但它的意义只在纯 JS 数值运算上下文中成立；一旦离开这个环境，就得靠协议约束和类型声明来兜底。
Number.MIN_SAFE_INTEGER-9007199254740991-9007199254740991 - 1-9007199254740992-9007199254740990id ，得确认它没超出安全整数范围。Number.isSafeInteger(id) && id <= 0id >= Number.MIN_SAFE_INTEGERNaNInfinity"-9007199254740992"parseInt()Number()Number.MIN_VALUE5e-324Number.MIN_SAFE_INTEGERif (value >= Number.MIN_SAFE_INTEGER && value <= Number.MAX_SAFE_INTEGER && value >= Number.MIN_VALUE) {
// 这里 value >= Number.MIN_VALUE 实际过滤掉了所有负数！
}
Number.isSafeInteger(value)Number.isInteger(value) && value >= Number.MIN_SAFE_INTEGER && value <= Number.MAX_SAFE_INTEGERNumber.MIN_SAFE_INTEGERNumber.MIN_SAFE_INTEGER-2147483648"id": "-9007199254740991"