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

BigInt内存开销不固定，取决于数值大小和引擎实现；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，但该 API 仅限调试，不可用于生产逻辑

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

Float64Array 或普通 number 字面量在内存中始终以 IEEE 754 双精度格式存在，固定 8 字节、小端序（x64 平台），且对齐到 8 字节边界。这带来两个关键事实：

• 数组连续存放时，Float64Array(n) 占用精确 n * 8 字节（不含对象头）
• 在 WebAssembly 或 TypedArray 与 C++ 交互时，可安全做 reinterpret_cast<double></double>，无需额外序列化
• 但要注意：Number.MAX_SAFE_INTEGER 之后的整数无法无损表示为 number，强制转 BigInt 会触发隐式 bigint 构造，开销陡增

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

当处理大规模数值计算（如密码学大数运算、科学模拟索引）、或对接 WASM/FFI 时，以下问题高频出现：

• 误用 JSON.stringify(bigint)：直接报错，必须手动实现序列化逻辑，否则 pipeline 中断
• 把 BigInt 放进 Map 或 Set 当 key：虽然合法，但哈希计算比 number 慢 3–5 倍（V8 11.5 测试数据），高吞吐下成瓶颈
• 跨线程传递 BigInt：SharedArrayBuffer 不支持，必须走 postMessage 序列化，而 Transferable 列表里没有 BigInt，意味着每次都是深拷贝

真正影响性能的从来不是“单个值占几字节”，而是值如何被分配、对齐、缓存、传输。尤其在密集数值计算中，BigInt 的非均匀内存分布会让 CPU 缓存行利用率骤降，这点比 Float64 的固定布局难优化得多。