高算力场景下BigInt与Float64内存布局差异评估

先说一个核心判断：BigInt 的内存开销不是固定的，完全取决于你存的整数有多大，以及 JS 引擎具体怎么实现；而 Float64 就很老实，固定 8 字节，对齐方式也完全可以预料。在真正高强度的计算场景里，真正该盯着的不是“一个数占几个字节”这种表面问题，而是分配、对齐、缓存命中以及数据传输这些底层环节。

一句话总结先行：BigInt 在 JS 中不按固定字节对齐，Float64 固定占 8 字节；高算力场景下，千万别只盯着 sizeof 或者 Number.isFinite 就以为摸清了内存开销的底细。

BigInt 的底层存储不是“一个数占多少字节”

JS 引擎（V8、SpiderMonkey 都一样）对 BigInt 背后玩的是动态多精度表示这套逻辑。数值越小，实际占用的内存越少；一旦你搞了个超大整数，引擎会把它拆成多个 32 位或 64 位的“字词”（words）拼接起来存。这就导致几个很现实的问题：

• 试着对比一下 BigInt(1) 和 BigInt("1" + "0".repeat(1000)) ——这两个玩意儿的内存占用差距能到百倍以上。
• 根本没有所谓 sizeof 等价物这种操作。new ArrayBuffer(BigInt(123n).toString().length) 这种写法完全反映不了真实的内存布局。
• 在 V8 里，你倒是可以靠 %DebugPrint(value)（前提是开启 --allow-natives-syntax）来窥探一下内部 BigInt 对象的 word count，但这玩意儿纯属调试专用，绝对不能拿到生产环境里当逻辑判断。

Float64 的内存布局是确定且可预测的

Float64Array 或者普通的 number 字面量，在内存里永远乖乖地以 IEEE 754 双精度格式存在。固定 8 字节，x64 平台采用小端序，并且天然对齐到 8 字节边界。这带来了两个关键事实：

• 数组要是连续存放的话，Float64Array(n) 占用的就是精确的 n * 8 字节（当然，不含对象头）。
• 在 WebAssembly 或者 TypedArray 跟 C++ 打交道时，你可以安全地做 reinterpret_cast 这种操作，完全不需要额外序列化。
• 这里必须提个醒：Number.MAX_SAFE_INTEGER 之后的整数，是无法无损地用 number 表示的。如果你强行转成 BigInt，会触发隐式的 bigint 构造，那开销一下就上去了。

高算力场景下容易踩的三个坑

当你进入大规模数值计算（比如密码学里的大数运算、科学模拟的索引），或者对接 WASM/FFI 时，下面这几个问题出现频率极高：

• 误用 JSON.stringify(bigint)：直接报错。你必须手动实现序列化逻辑，否则管线就断了。
• 把 BigInt 放进 Map 或 Set 当 key：虽然语法上合法，但哈希计算比 number 慢 3 到 5 倍（V8 11.5 版本的测试数据）。在高吞吐场景下，这就会变成明显的瓶颈。
• 跨线程传递 BigInt：SharedArrayBuffer 并不支持它，只能走 postMessage 序列化。而且 Transferable 列表里压根没有 BigInt 的身影，意味着每一次传递都是深拷贝。

最后说一句大实话：真正影响性能的，从来不是“单个值占几个字节”这种表面数字。关键是值是怎么被分配的、怎么对齐的、缓存命不命中、以及数据传输的效率。特别是在密集数值计算里，BigInt 那种非均匀的内存分布，会让 CPU 缓存行的利用率直线下降。相比之下，Float64 的固定布局简直是模范生，优化起来要轻松得多。