javascript数值精度问题源于ieee 754双精度浮点格式的52位尾数限制，导致安全整数范围为±9007199254740991，超出后整数“跳号”；小数从第17位有效数字起不可靠，如0.1+0.2≠0.3；极大极小值仅具数量级意义，精度与表示范围无关。
JavaScript 数值精度问题有两个核心界限：一个是整数安全范围，另一个是小数表示能力。两者都源于 IEEE 754 双精度浮点格式的固有结构——64 位中仅 52 位用于尾数（实际有效精度约 53 个二进制位），导致它既不能精确表示所有十进制小数，也不能无损表达超大整数。
安全整数范围：±9007199254740991
这是最常被忽视也最关键的界限：
- Number.MAX_SAFE_INTEGER === 9007199254740991（即 2⁵³ − 1），超出后相邻可表示整数的间隔大于 1，出现“跳号”
- 例如：
9007199254740992 + 1 === 9007199254740992，+1 不再生效 -
Number.isSafeInteger(9007199254740991)返回 true；Number.isSafeInteger(9007199254740992)返回 false - 后端传来的长整型 ID（如 64 位时间戳、MongoDB ObjectId）若直接转为 Number，极易在此范围外失真，应作为字符串处理
小数精度失效：从第 17 位十进制有效数字开始不可靠
不是小数位数多就出错，而是有效数字总位数触及 53 位二进制精度上限：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 0.1 和 0.2 在二进制中是无限循环小数，存储时被截断，所以
0.1 + 0.2 !== 0.3 - 看似简单的
1.335.toFixed(2)得到"1.33"，因为内部实际值是1.3349999999999999645 - ECMAScript 输出逻辑会自动选择“最短可往返字符串”，所以
console.log(0.3)显示0.3，但console.log(0.1 + 0.2)显示0.30000000000000004——后者已无法用 "0.3" 精确还原
数值表达极限：远超精度，但失去意义
虽然 JavaScript 能表示极大或极小的数，但超出精度范围后只剩数量级参考价值：
-
最大可表示值：
Number.MAX_VALUE ≈ 1.798e+308，再大变成Infinity -
最小正可表示值：
Number.MIN_VALUE ≈ 5e-324，更小的正数会下溢为0 - 这些边界与精度无关——
1e300是精确值，但9007199254740991111（19 位）已无法精确表示，哪怕远小于MAX_VALUE
判断与应对的关键习惯
日常编码中守住精度，不靠经验靠机制：
- 整数运算前先用
Number.isSafeInteger()校验，尤其涉及 ID、计数器、分页偏移量 - 小数比较不用
===，改用Math.abs(a - b) （≈2.22e-16） - 金融计算不用原生 Number，改用
BigInt（整数）、decimal.js或字符串模拟运算 - 显示小数时，
toFixed()返回字符串，需parseFloat()转回数字——但注意它不修复底层精度，只控制输出
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
