JavaScript的Number类型是IEEE 754双精度浮点数，整数精度仅在±2⁵³−1内可靠；超出后发生静默精度丢失，如9007199254740992与9007199254740993相等；应使用Number.isSafeInteger检测、BigInt或字符串处理越界整数。
JavaScript 的 Number 类型本质是 IEEE 754 双精度浮点数，它能表示极大极小的值，但整数精度只在 ±2⁵³ − 1 范围内完全可靠。超出这个范围，看似“还能算”，实则已开始丢精度——这不是报错，而是静默失真，最容易在关键逻辑中埋下隐患。
安全整数边界：不是上限，而是精度分水岭
Number.MAX_SAFE_INTEGER 是 9007199254740991（即 2⁵³ − 1），Number.MIN_SAFE_INTEGER 是 −9007199254740991。这组值定义的不是“最大能存多少”，而是“每个整数都能被唯一、精确表示”的范围。
- 9007199254740992 和 9007199254740993 在 JS 中完全相等（
===返回 true） - 执行
Math.pow(2, 53) + 1得到的仍是 9007199254740992，+1 没生效 - 数组长度理论上可超此值，但索引访问、
for...in等行为不可靠，实际开发中应避免
常见越界场景与典型失真表现
很多问题不是出现在显式输入超大数时，而是在组合运算或跨系统交互中悄然发生：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
ID 处理：后端返回
{"id": 9007199254740992}，前端JSON.parse后 id 已变成 9007199254740992（正确），但若后端实际想传 9007199254740993，JS 里就收不到了 -
时间戳拼接 ID：例如
Date.now() * 1000000 + counter，毫秒级时间戳约 17 位，乘以 10⁶ 后轻松突破 2⁵³，counter 再加一可能直接被抹平 -
金额累加：未使用
BigInt或 decimal 库时，连续做小数或大整数加法，误差会累积，比如0.1 + 0.2 !== 0.3是经典浮点误差，而大额整数加法也可能跳号
检测与防护：别只比大小
仅用 n > Number.MAX_SAFE_INTEGER 判断远远不够，因为中间运算可能已失真。可靠做法是：
立即学习“Java免费学习笔记（深入）”；
- 对单个数值：用
Number.isSafeInteger(n)—— 它同时检查是否为整数、是否在安全范围内、是否为有限值 - 对运算结果：先计算，再立刻验证，如
const sum = a + b; if (!Number.isSafeInteger(sum)) { /* 改用 BigInt */ } - 接收 JSON 数据时：对 ID、序列号等关键字段，后端应统一返回字符串（如
"id": "9007199254740992"），前端全程按字符串处理，不转Number
越界后的实用应对策略
一旦确认可能越界，硬扛 Number 不是办法，要主动切换类型或协议：
- 优先使用
BigInt：支持任意精度整数，写法如9007199254740992n或BigInt("9007199254740992")；注意它不能和Number混用（1n + 2报错） - ID 类字段全程字符串化：生成、传输、存储、比较都用字符串，彻底绕过精度陷阱
- 金融/高精度计算改用专用库：如
decimal.js（支持小数精度控制）、big.js（轻量替代） - 服务端配合：对长整型字段，API 文档明确要求返回字符串格式，并在 Swagger/OpenAPI 中标注
type: string, format: int64
