javascript数值类型统一为ieee 754双精度浮点数,导致0.1+0.2≠0.3、安全整数范围限于±(2^53−1)、nan不等于自身;超大整数用bigint,精度敏感场景需转整数运算或使用decimal.js等库。

JavaScript 的数值类型看似简单,实则暗藏细节。它只有一个 Number 类型,底层是 IEEE 754 双精度 64 位浮点数,这决定了它的能力边界和常见陷阱。
数值的统一性与存储本质
JS 中没有 int、float、double 等区分。无论是 42、3.14159 还是 1e20,全部按相同格式存入 64 位内存:1 位符号 + 11 位指数 + 52 位尾数。这种设计带来便利,也埋下隐患。
- 所有整数在
−2^53 + 1到2^53 − 1(即Number.MIN_SAFE_INTEGER至Number.MAX_SAFE_INTEGER)范围内才是“安全整数”,超出后可能丢失精度或出现相邻整数相等的情况 -
0.1 + 0.2 !== 0.3不是 bug,而是二进制无法精确表示十进制小数 0.1 和 0.2 的必然结果 - 特殊值如
Infinity、-Infinity和NaN都属于 Number 类型,但NaN !== NaN,必须用Number.isNaN()或isNaN()判断
安全整数与大数处理
当需要处理超过 2^53 − 1(约 9007199254740991)的整数时,原生 Number 已不可靠。
基于三引擎设计,从微信文章、新闻和博客网页提取干净内容,支持标题作者日期元数据,多格式和批量处理。
- 使用
Number.isSafeInteger(n)可快速验证一个数值是否在安全整数范围内 - ES2020 引入的
BigInt提供任意精度整数支持,写法为末尾加n(如123456789012345678901234567890n),但不能与普通 Number 混合运算,也不能用于 Math 方法或小数点后数字 - 对超大整数做算术运算前,务必检查类型一致性,避免隐式转换导致精度丢失或
TypeError
类型判断与数值校验
由于 JS 是弱类型语言,输入常不可控,严谨的数值操作离不开前置校验。
-
typeof x === 'number'只能排除非数值类型,但无法区分NaN或Infinity - 推荐组合使用:
typeof x === 'number' && !isNaN(x) && isFinite(x)才能确认是一个常规有限数值 - 对于字符串转数值,优先用
Number()而非parseInt()或parseFloat(),除非明确需要截断解析;Number(' 42 ')返回42,而Number('42px')返回NaN,更符合语义预期
精度控制与实用应对策略
金融、计费、UI 展示等场景对小数精度敏感,不能依赖原始浮点运算结果。
- 货币计算建议统一转为整数(单位:分)进行运算,避免小数参与中间过程
- 显示格式化推荐用
toFixed(n)(注意返回字符串)或Intl.NumberFormat(支持多语言、千分位、舍入规则) - 需高精度浮点运算时,可引入成熟库如
decimal.js或big.js,它们提供可控舍入模式(如四舍五入、向上取整、银行家舍入)和固定精度配置










