javascript number 精度丢失的根本原因是采用 ieee 754 64 位双精度浮点数表示，导致整数安全范围限于 ±(2^53−1)，超出则舍入；十进制小数如 0.1 在二进制中无限循环，52 位尾数截断后存储近似值，故 0.1+0.2=0.30000000000000004；js 无独立整数类型，所有数字统一按浮点规则处理。
JavaScript 的 Number 类型精度会丢失，根本原因在于它用 64 位双精度浮点数（IEEE 754 标准）表示所有数字，而这种表示法天然无法精确存储某些十进制数，也无法无损表达超大整数。
JavaScript Number 的精度限制本质
-
安全整数范围有限：能精确表示的整数仅限于
-(2^53 - 1)到2^53 - 1（即 ±9007199254740991）。超出这个范围的整数，二进制尾数位不够，系统会自动舍入——比如9007199254740992 + 1仍等于9007199254740992。 -
浮点数二进制表示失真：十进制小数如
0.1、0.2在二进制中是无限循环小数（类似十进制中1/3 = 0.333…），但 IEEE 754 只保留 52 位尾数，必须截断 → 存储的是近似值。所以0.1 + 0.2实际计算的是两个近似值之和，结果为0.30000000000000004。 -
没有单独的整数类型：JS 中
123和123.0都是Number，底层统一用浮点格式存，连“纯整数”也受浮点规则约束。
常见触发场景
- 后端传来的 long ID（如
12345678901234567890）被 JSON 解析成Number，前端读到的已是四舍五入后的错误值； - 金额计算中连续加减小数（如
0.1 + 0.2 + 0.3），误差累积； - 大数参与运算后调用
.toString()或JSON.stringify()，输出已失真； - 使用
toFixed()时发现结果不符合数学四舍五入（因输入本身已是近似值）。
不是 bug，而是设计取舍
IEEE 754 是通用、高效、硬件支持的数值表示标准。JS 选择它是为了兼容性与性能，而非高精度计算——这本就不是它的设计目标。
简单说：JS 的 Number 就像一把只有 16 位刻度的尺子，量得下日常尺寸，但测纳米或光年就会“凑合着标一个最接近的刻度”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
