javascript的number类型基于ieee 754双精度浮点数，导致安全整数范围限于±(2⁵³−1)，超出则精度丢失；小数运算因二进制舍入产生误差；类型转换存在隐式陷阱；无原生精度控制，高精度场景需依赖bigint或第三方库。

javascript 的 number 类型本质是 ieee 754 双精度浮点数，它不区分整数和小数，所有数字都按同一套规则存储和运算。这种设计带来便利的同时，也决定了它的精度边界和运算行为——不是“不准”，而是“按标准算得没错，但结果不符合十进制直觉”。

安全整数范围：超出就失真

JavaScript 能精确表示的整数仅限于 ±9007199254740991（即 ±(2⁵³ − 1)）。这个值可通过 Number.MAX_SAFE_INTEGER 和 Number.MIN_SAFE_INTEGER 获取。

• 超过该范围后，相邻可表示整数之间的间隔大于 1，+1 可能毫无效果：9007199254740992 + 1 === 9007199254740992
• 后端传来的 64 位 ID（如 Snowflake）、高精度时间戳（毫秒级以上），若直接用 Number 解析，极易被静默截断或四舍五入
• Math.floor(10000000000000001) 返回 10000000000000000，不是计算错误，而是该数已超出安全范围，底层已无法区分

小数运算：二进制舍入不可避免

十进制小数（如 0.1、0.2）在二进制中是无限循环小数，必须截断存储，误差从存入那一刻就已存在。

Alibabacloud Sdk Client Initialization For Java

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

下载

• 0.1 + 0.2 === 0.30000000000000004，不是 JS bug，而是 IEEE 754 的标准行为
• 1.005.toFixed(2) 返回 "1.00" 而非 "1.01"，因浮点内部表示实际略小于 1.005，舍入规则导致向下取整
• 金融类连续运算（如利息累加、汇率换算）会放大初始误差，单次误差虽小，多轮叠加后可能显著偏离预期

类型转换与隐式行为：容易踩坑

Number 在与其他类型交互时自动转换，但规则并不总是直观，尤其在解析字符串时。

• parseInt("08") 在非严格模式下返回 0（旧版八进制解析歧义），而 parseInt("0x10") 正确返回 16
• +"1.2e50" 得到 Infinity，但 +"1.2e3" 是 1200，同样写法，结果天差地别
• 用 new Number(0) 创建对象，其布尔值为 true（对象恒真），而原始值 0 为 false，易引发条件判断错误

没有原生精度控制：靠开发者兜底

Number 本身不提供有效位数设定、舍入策略选择或误差容忍机制。

• 不能像数据库字段那样声明 DECIMAL(10,2) 来约束精度
• toFixed() 返回字符串，且对临界值行为不稳定；toPrecision() 控制有效位而非小数位，适用场景有限
• 需要高精度场景（如支付、科学计算）时，必须引入第三方库（如 decimal.js、big.js）或使用原生 BigInt 处理大整数

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