JavaScript数值精度问题源于IEEE 754双精度标准，非自身缺陷；其选择双精度是为兼顾范围、精度与硬件支持；BigInt（ES2020）和decimal.js等库是对该限制的工程补全。
JavaScript 中的数值精度问题，不是它自己“发明”的缺陷，而是继承自整个计算机科学底层的浮点数表示传统——其历史渊源可追溯到 1985 年 IEEE 754 标准的确立。
IEEE 754 是一切的起点
在 JavaScript 诞生（1995 年）之前近十年，IEEE 就已发布二进制浮点数算术标准（ANSI/IEEE Std 754-1985）。该标准统一了硬件与软件对浮点数的解释方式，被 Intel x87 协处理器、摩托罗拉 68881 等主流芯片采纳。JavaScript 作为运行于通用环境的脚本语言，自然选择兼容这一已被广泛实现的工业标准，而非另起炉灶。
这意味着：0.1 + 0.2 !== 0.3 这类现象，并非 JS 设计失误，而是所有遵循 IEEE 754 双精度（64 位）的系统共有的行为——C、Java、Python、Go 等语言同样如此。
为什么选双精度？权衡的结果
JavaScript 初期目标是轻量、通用、跨平台。采用双精度浮点数（而非单精度或定点数），是为了兼顾三方面：
立即学习“Java免费学习笔记（深入）”；
- 足够大的数值范围（约 ±1.8 × 10308），满足网页中常见计算需求；
- 相对较高的有效位数（约 15–17 位十进制数字），比单精度更可靠；
- 硬件直接支持——当时绝大多数 CPU 已内置双精度浮点运算单元，性能开销极小。
这种设计在 1990 年代是务实之选，却也把“十进制小数无法精确表示”这一数学本质问题，一并带进了 JS 的基因里。
从“无整数类型”到 BigInt 的缓慢补全
早期 JS 没有独立的整数类型，所有数字都是 Number（即双精度浮点数），连 1 和 1.0 都是同一类型。这加剧了开发者对“精度理应完美”的误解。
直到 ES2020（2020 年），BigInt 才正式成为标准，允许表示任意精度整数（如 123n）。但它不与 Number 混用，且不支持小数——说明高精度并非简单“升级 Number”，而是需要新类型、新语义、新生态。
同理，decimal.js、bignumber.js 等库的流行，也印证了：标准演进慢，而工程实践早已自发填补空白。
中文术语“数值精度”的正式确立
“数值精度”作为规范术语，是在 2008 年由海峡两岸信息科学技术名词审定委员会公布的。它并非 JS 特有概念，而是对“数值能精确到多少位数”这一共性指标的统一命名。JS 开发者今天讨论的精度问题，本质上是在这个跨学科术语框架下的具体应用案例。
