JavaScript数值类型统一用Number（IEEE 754双精度浮点数）表示，安全整数范围±9007199254740991；ES2020引入BigInt补足大整数需求，但需环境支持且不兼容Number；生产中默认用Number，精度敏感场景应借助decimal.js等库。
JavaScript 的数值类型定义从诞生起就带着务实与妥协的烙印，它没有独立的整数、浮点数或大整数类型，而是统一用 Number 类型表示所有数字——这个设计沿用至今，也直接塑造了开发者日常面对的精度、边界和兼容性问题。
Number 类型的原始定义：IEEE 754 双精度浮点数
1995 年 Brendan Eich 设计 JavaScript 时，为简化实现、保证跨平台一致性，直接采用 C 语言中 double 的底层表示：64 位 IEEE 754 双精度浮点格式。这意味着：
- 所有数字（包括
42、3.14、0、-0、Infinity、NaN）都属于Number类型； - 安全整数范围是
-(2⁵³ - 1)到2⁵³ - 1（即±9007199254740991），超出后无法精确表示； - 没有原生整数类型，
1和1.0在引擎内部完全等价； -
typeof 42返回"number"，typeof NaN也是"number"（这是历史遗留的怪异行为）。
这个设计在当时浏览器资源受限的环境下极为高效，但也埋下了长期存在的陷阱，比如：
0.1 + 0.2 === 0.3 // false → 实际值是 0.30000000000000004
历史演进中的关键补充：BigInt 与 Number 的共存
直到 ES2020（ECMAScript 11），JavaScript 才正式引入 BigInt 类型，用于表示任意精度的整数：
立即学习“Java免费学习笔记（深入）”；
- 字面量写法：
123n（末尾加n）； -
typeof 123n返回"bigint"，与Number严格区分； -
BigInt不能与Number混合运算（1n + 1报错），必须显式转换； -
BigInt不支持小数、指数语法，也不参与Math对象的多数方法。
它的出现不是替代 Number，而是补足其短板——尤其在密码学、高精度计时、大 ID 处理等场景。但要注意：
-
BigInt在 IE 全系不支持，旧版 Safari（<14）、旧版 Edge（<79）也不支持； - JSON 不支持
BigInt（JSON.stringify(123n)抛错），需手动处理； -
==会尝试隐式转换（123n == 123为true），但===严格不等（123n === 123为false）。
兼容性现实：Number 仍是事实标准，BigInt 是“按需启用”
几乎所有运行环境（包括 Node.js 10.4+、Chrome 67+、Firefox 68+、Safari 14+）现在支持 BigInt，但生产代码中仍需谨慎：
- 服务端若需兼容 Node.js <10.4，应避免
BigInt； - 前端项目若需支持 iOS 13 或 Android WebView 旧版本，建议用
big-integer等库模拟； -
Number.isSafeInteger()是检测整数是否可安全表示的可靠手段，比Number.MAX_SAFE_INTEGER更实用； -
Number()构造函数可将字符串转为数字，但parseInt()和parseFloat()仍有各自语义（如忽略前导空格、支持进制参数等），不可随意替换。
小结：数值类型的兼容性策略
- 默认使用
Number，它是唯一被所有环境无条件支持的数值类型； - 需要大于
2⁵³的整数时，先确认目标环境支持BigInt，再用n后缀声明； - 涉及金融、科学计算等精度敏感场景，不要依赖浮点运算结果，优先用
decimal.js或big.js等库； -
NaN和Infinity虽属Number，但它们是特殊值，isNaN()已被Number.isNaN()替代（后者不强制转类型，更可靠）。
本质上，JavaScript 的数值模型没变——它始终是“一个浮点数类型 + 一个后来加入的整数扩展”。理解这个起点，才能避开大多数精度和兼容性坑。
