Number.MIN_SAFE_INTEGER是JavaScript中可精确表示的最小整数（−9007199254740991），非配置项，不可赋值；业务需显式校验而非依赖其设阈值。
Number.MIN_SAFE_INTEGER不是用来“设定阈值”的常量
Number.MIN_SAFE_INTEGER 是一个只读静态属性，值为 -9007199254740991（即 −(2⁵³ − 1)），它描述的是 JavaScript 中能**被精确表示的最小整数**，不是配置项，也不能赋值或修改。试图用它“设定”业务阈值，本质是误解了它的用途——它只是告诉你“再小就可能丢精度”，而不是“小到这个数就要拦截”。
业务中真正需要做的是显式校验，而非依赖赋值
如果你的业务逻辑要求输入不能低于某个安全下界（比如订单 ID、账户余额、时间戳偏移等），你应该主动做判断，而不是指望把 Number.MIN_SAFE_INTEGER 当成开关或配置项塞进某处。
- 错误做法：
let minThreshold = Number.MIN_SAFE_INTEGER;然后直接用这个变量参与后续逻辑，以为“设了就生效” - 正确做法：在关键路径上插入校验，例如：
if (!Number.isSafeInteger(value) || value
- 注意：
Number.isSafeInteger(value)已隐含检查了value >= Number.MIN_SAFE_INTEGER和value ，所以单独再比一次多余，但保留可提升可读性
为什么直接用 Number.MIN_SAFE_INTEGER 做边界容易出错
常见误用场景包括：把它当默认值传给后端、硬编码进配置对象、或作为函数参数默认值。问题在于：
-
Number.MIN_SAFE_INTEGER是数值，不是业务语义——你的业务“最低允许订单号”可能是1，不是-9007199254740991 - 它不解决负数大整数的序列化问题：比如
JSON.stringify(-9007199254740992)仍会输出错误值，因为精度已丢失 - 某些环境（如旧版 Node.js 或压缩工具）可能对超大字面量解析异常，写死
Number.MIN_SAFE_INTEGER并不能规避
更稳妥的替代方案：按场景选类型 + 显式防护
当业务确实涉及接近或低于 Number.MIN_SAFE_INTEGER 的值时，优先考虑：
- 用字符串接收和传递：后端返回
"-9007199254740992"，前端不转Number，避免解析阶段就失真 - 必要计算时改用
BigInt：例如BigInt('-9007199254740992')，但注意BigInt不能和Number混算，且不支持小数 - 校验逻辑前置：在表单提交、API 请求封装层就调用
Number.isSafeInteger()，失败则提示用户或自动转字符串
真正的难点不在记住那个数字，而在于识别哪些字段“看起来像数，实则是标识符”——订单号、用户 ID、加密 nonce 都属于这一类，它们压根不该进 Number 类型流转。
