javascript中number类型能精确表示的最大整数是9007199254740991，源于ieee 754双精度浮点数53位尾数限制；超出后加减1失效，需用bigint、字符串或number.issafeinteger()规避精度丢失。

JavaScript 中 Number 类型能精确表示、可靠运算的最大整数是 9007199254740991，最小安全整数是 −9007199254740991。这个范围不是由内存或引擎限制决定的，而是 IEEE 754 双精度浮点数格式的数学必然结果——53 位有效数字（含隐含位）决定了整数能被唯一、无损表示的边界。

为什么是 2⁵³ − 1？

JavaScript 所有数字都按双精度浮点格式存储（64 位），其中尾数部分提供 53 位二进制精度。这意味着：

• 从 0 到 2⁵³ − 1（即 9007199254740991）之间的每个整数都有唯一的浮点表示；
• 一旦达到或超过 2⁵³（9007199254740992），相邻可表示的数之间间隔 ≥ 2，导致像 9007199254740992 === 9007199254740993 这样的比较返回 true；
• 加减 1 不再可靠：9007199254740992 + 1 仍等于 9007199254740992，精度已丢失。

别混淆：MAX_SAFE_INTEGER ≠ MAX_VALUE

Number.MAX_SAFE_INTEGER 和 Number.MAX_VALUE 完全不同：

js2java

JavaScript 到 Java 全栈翻译助手，专为前端开发者学习 Java 或快速实现后端业务逻辑而设计。当用户提到以下场景时必须使用此技能： - "帮我把这段 JS 代码转成 Java" - "用 Java 怎么写这个逻辑" - "我习惯用 JS 写，想翻译成 Java" - "教我 Java，我要写后端接...

下载

• Number.MAX_SAFE_INTEGER === 9007199254740991：强调“整数精度不丢”；
• Number.MAX_VALUE ≈ 1.798e+308：只是能表示的**最大浮点近似值**，里面绝大多数整数根本无法区分；
• 大数如 Math.pow(2, 1000) 可存，但不是精确整数——就像用米尺量毫米级差异，刻度不够细。

如何检测和应对越界？

不能只靠大小比较，要主动校验和选对类型：

• 用 Number.isSafeInteger(n) 判断单个数值是否在安全范围内（返回 true 仅当 n 是有限整数且落在 ±9007199254740991 内）；
• 后端传 ID、时间戳等大整数时，应统一用字符串字段（如 "id": "9007199254740992"），避免 JSON 自动解析成失真 Number；
• 需运算时优先用 BigInt（如 9007199254740992n），注意它不能与 Number 混用，且不支持 JSON 原生序列化；
• 纯展示、校验或中转场景，字符串最简单零风险——可直接比较、格式化、拼接，无需转换。

常见静默错误场景

这些地方最容易踩坑，且不易察觉：

• 前端生成自增 ID 或拼接时间戳作为唯一键，超限后出现重复 ID；
• 从接口拿到长数字 ID（如雪花 ID），JSON 解析后变成近似值，后续 === 匹配失败；
• 金额计算中误用 Number 处理千万级以上整数，四舍五入或相等判断出错；
• 调用 parseInt 或 Number() 转字符串大数时，输入已失真，再校验也晚了。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南