应使用 Number.isSafeInteger() 判定安全整数，先确保字段为 number 类型，再验证是否在 [-MAX_SAFE_INTEGER, MAX_SAFE_INTEGER] 范围内且为整数；字符串 ID 需避免隐式转换，超长数字字符串应直接拒绝或用 BigInt 处理。
不能直接用 Number.MAX_SAFE_INTEGER 做判定，它只是一个数值常量（9007199254740991），本身不具备检测能力。真正起作用的是配合类型和范围检查的逻辑判断——核心是：**先确认字段是 number 类型，再看它是否 ≤ Number.MAX_SAFE_INTEGER 且 ≥ -Number.MAX_SAFE_INTEGER，同时确保它没被隐式转换污染过。**
为什么不能拿字符串 ID 直接比 MAX_SAFE_INTEGER
后端返回的长 ID 如果是字符串（如 "9223372036854775807"），你不能写 idStr > Number.MAX_SAFE_INTEGER——JS 会先把它转成 number，而这个转换过程已经丢失精度。例如：
-
Number("9007199254740993") === 9007199254740992（末位被抹平） - 此时再拿这个错值去和
MAX_SAFE_INTEGER比，结果毫无意义
真正有效的判定路径是“先转再验”，且仅限 number 字段
只对 JSON 中明确以数字形式下发的字段（比如 {"id": 9007199254740993}）才适用。步骤如下：
- JSON 解析后立即获取该字段值（此时已是 number 类型）
- 调用
Number.isSafeInteger(value)—— 它内部已封装了value >= -MAX_SAFE_INTEGER && value - 返回
false就代表该值已不可信，可能被截断或四舍五入
更前置的防护：在解析前就拦截高风险字符串
如果后端把 ID 当字符串发（推荐做法），那你根本不需要 MAX_SAFE_INTEGER 参与判定。但若想提前过滤明显超长的 ID 字符串，可用长度+正则：
- 用
/^\d{17,}$/.test(idStr)快速识别 ≥17 位的纯数字字符串（因为 16 位数中已有部分超出安全范围） - 这类字符串一旦被误转为 number，100% 失真，应直接拒绝转换或打警告日志
- 不建议用
parseInt(idStr) > Number.MAX_SAFE_INTEGER，因parseInt在超大数下也会失真
判定后的响应动作比判定本身更重要
发现 Number.isSafeInteger(id) === false 后，不能只抛个错误就结束。要结合业务决定：
- 是 ID 字段？→ 立即改用原始字符串渲染、传参、作 key
- 是金额或计数器？→ 改用
BigInt(idStr)进行后续运算，避免混用 number - 是调试场景？→ 把原始响应体和
JSON.parse()后结果并列打印，快速定位精度在哪一步丢失
