number.issafeinteger只对number类型有效，字符串需先转数字再校验；超大数应优先用正则/^\d{1,16}$/过滤，或改用bigint；json解析后应立即校验，避免精度丢失。
Number.isSafeInteger 为什么不能直接判断大数字符串
它只对 number 类型有效，传入 "9007199254740992" 这种字符串会立刻返回 false——不是因为数值越界，而是类型不对。实际项目中常有人把后端传来的长数字 ID 当成字符串处理，却误用 Number.isSafeInteger 做校验，结果永远不通过。
正确做法是先尝试转换，再判断：
- 用
Number()或一元加号+转换，但注意Number("123abc")会得NaN，需额外检查 - 转换后立即用
Number.isSafeInteger()，不要跳过这步——比如9007199254740993是合法number，但已超出安全整数范围 - 避免用
parseInt()，它会截断小数、忽略末尾非数字字符，导致误判
判断前必须确认数值未被 JS 自动转成科学计数法
当原始数字极大（如 123456789012345678901234567890），JS 在解析时可能直接变成 1.2345678901234568e+29，此时 Number() 结果已是近似值，Number.isSafeInteger() 失去意义。
所以真正安全的前置检查其实是：先看输入是否为纯数字字符串，且长度不超过 16 位（Number.MAX_SAFE_INTEGER 是 9007199254740991，共 16 位）：
- 用正则
/^\d{1,16}$/快速过滤，比解析再判断更可靠 - 如果业务允许，直接限制输入长度（例如 ID 字段后端约定 ≤16 位），前端连
Number.isSafeInteger都不用调 - 若必须支持超长整数（如区块链地址），就别走
number路线，改用BigInt或字符串运算库
和 Number.MAX_SAFE_INTEGER 手动比较的区别在哪
有人写 n = -Number.MAX_SAFE_INTEGER && Number.isInteger(n)，看似等价，其实多此一举且有隐患。
Number.isSafeInteger(n) 内部已经做了三件事：类型是 number、是整数、且在安全范围内。手动拆解反而容易漏掉边界条件：
-
Number.isInteger(NaN)返回false，但NaN 是 <code>false，逻辑不一致 -
Number.isInteger(Infinity)是false，而Infinity > MAX_SAFE_INTEGER是true，手动比较会误判 - 浮点数如
5.0是Number.isInteger()的合法输入，但手动比较没做整数性校验，可能放过5.1
在 JSON 解析后立刻校验的典型场景
后端返回的 JSON 中字段值是数字，但前端不确定它是否超限（尤其 ID、金额、时间戳等）。这时不能等到计算时才发现精度丢失。
推荐在 JSON.parse() 后、业务逻辑前插入一层校验函数：
function validateSafeIntegers(obj) {
for (const key in obj) {
if (typeof obj[key] === 'number' && !Number.isSafeInteger(obj[key])) {
throw new Error(`Unsafe integer at ${key}: ${obj[key]}`);
}
if (typeof obj[key] === 'object' && obj[key] !== null) {
validateSafeIntegers(obj[key]);
}
}
}
注意：这个函数不处理字符串数字，也不递归进数组索引——如果 API 明确某字段应为整数 ID，就该让后端返回字符串，前端不主动转 number。
最易被忽略的一点：Chrome 控制台里打印大数看起来正常，不代表它没丢精度。比如 9007199254740993 和 9007199254740992 在 console.log 中都显示为 9007199254740992，但它们的 Number.isSafeInteger() 结果不同。别信眼见为实。
