根本原因是javascript的number类型遵循ieee 754双精度标准，用64位二进制近似表示十进制数，导致0.1等小数转二进制时无限循环而被截断，加之尾数仅52位、安全整数上限为2^53−1，且运算中每步均舍入，误差累积；json解析大整数时更因类型强制转换加剧精度坍塌。

JavaScript 中 Number 类型处理浮点数时出现精度丢失，根本原因在于它严格遵循 IEEE 754 双精度浮点数标准，而该标准用有限的 64 位二进制来表示无限多的十进制实数——这种表示方式天然存在无法精确表达的部分。

二进制无法精确表示某些十进制小数

计算机内部只认二进制，而像 0.1、0.2、0.3 这类十进制小数，在转成二进制时会变成无限循环小数（例如 0.1₁₀ = 0.0001100110011…₂）。由于存储空间固定（尾数部分仅 52 位），系统只能截断或舍入，导致原始值被近似存储。后续所有运算都基于这个“有偏差”的近似值，误差自然累积。

安全整数范围受限于尾数精度

IEEE 754 双精度格式中，有效数字（尾数）实际可提供约 15–17 位十进制有效数字，但能**完全精确表示的整数上限是 2⁵³ − 1（即 9007199254740991）**。超过这个值，连续整数之间开始出现“空隙”——比如 9007199254740992 和 9007199254740993 在 Number 中可能被存为同一个值，因为尾数已无法区分它们。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

运算过程不保留中间精度

JavaScript 不对中间计算结果做额外精度保护。每次加减乘除都会重新按 IEEE 754 规则进行舍入（默认采用“四舍六入五成双”规则），而不是暂存高精度值。例如 0.1 + 0.2 并非先算出精确十进制结果再转二进制，而是分别将 0.1 和 0.2 存为近似二进制，再相加，最后再舍入输出——每一步都在损失精度。

JSON 序列化加剧整数精度问题

前后端通过 JSON 传输数据时，后端 long 类型（如 Java 的 64 位整数）若直接序列化为数字字面量（如 "id": 9223372036854775807），前端解析时会强制转为 Number。一旦超出 MAX_SAFE_INTEGER，高位比特就被丢弃或误读，ID 类字段极易错乱——这不是 JS 运算错误，而是数据载体（JSON 数字）和接收端类型（Number）共同导致的表示坍塌。

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