javascript中number类型统一使用ieee 754双精度浮点格式，固定8字节（1位符号+11位指数+52位尾数），故所有数字无论整数、小数或特殊值均等长存储，导致精度限制（如0.1+0.2≠0.3）和最大安全整数为2⁵³−1。
JavaScript 中的 Number 类型统一使用 IEEE 754 双精度浮点数格式，固定占用 8 字节（64 位） 内存，无论它是整数、小数、0、Infinity 还是 NaN。
为什么总是 8 字节？
JS 不区分 int、float、long 等子类型，所有数字都按同一标准存储：1 位符号位 + 11 位指数位 + 52 位尾数位。这意味着：
- 每个 Number 变量在栈中分配固定大小空间，利于快速读写和垃圾回收
- 没有“小整数更省内存”的优化（不像某些语言有 small integer cache）
- 即使写
let a = 1，底层仍是 64 位浮点表示，不是 32 位整数
内存固定 ≠ 数值安全
8 字节能表示的范围很大（≈ ±1.79e308），但精度受限于 52 位尾数：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
最大安全整数 是
Number.MAX_SAFE_INTEGER（2⁵³ − 1 = 9007199254740991） - 超过该值的整数可能丢失精度，例如
9007199254740992 === 9007199254740993返回true - 超大数值（如后端返回的 20 位订单 ID）若用 Number 接收，很可能被四舍五入或截断
对性能的实际影响
单个 Number 的开销极小，但高频场景下仍需注意：
-
数组密集运算：百万级数字数组（如 Canvas 像素处理、科学计算）会占用大量连续内存（每项 8B），建议用
Float64Array替代普通数组，避免包装对象开销 -
频繁装箱/拆箱：对基本数字调用方法（如
(42).toString()）会临时创建包装对象，虽由引擎优化，但极端循环中仍有微小成本 -
比较与转换：
==隐式转 Number、parseInt解析字符串等操作本身不改变内存占用，但会触发额外计算，应优先用===和Number()明确意图
超大整数怎么办？
当业务需要精确表示远超 2⁵³ 的整数（如区块链地址、高精度 ID）：
- 用 BigInt（ES2020）：以
n结尾（如123n），支持任意精度，但不能与 Number 混算，且暂不支持 Math 方法 - 保持为 字符串：适合只做传输、展示或简单校验的场景，避免精度丢失
- 服务端配合：改用字符串字段返回大数，前端不主动解析为 Number
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
