JS 物件比原始資料胖好幾倍

同一筆邏輯資料，變成 JS 物件之後佔的位元組數是原始 bytes 的好幾倍。不是資料變多，是每個值都被包了一層又一層。

對照

緊湊格式（例如 SQLite 的一列）就是一段連續 bytes，額外開銷只有一個 record header：

[record header][值1 bytes][值2 bytes]…[值33 bytes]     ≈ 460 bytes

同一列進到 JS：

{
  name: "冷軋鋼捲",                              // 字串是獨立的 heap object
  category: { label: "金屬", value: "metal" },   // 一個值 → 一個物件 + 兩個字串
  ...另外 30 個欄位
  rowStatus: "OK", errors: [], dirty: false      // 原始資料沒有的 UI 狀態
}

放大來自五件事

每個字串都是 heap object — 帶 map pointer、length、hash 等 header；短字串的 header 可能比字元本身還大，含非 Latin-1 字元（中文）還會整條升級成 two-byte 表示
物件本身的固定成本 — map pointer（指向 hidden class）、properties backing store、elements pointer，光是存在就要幾十 bytes
包裝把一個值變成三個東西 — {label, value} = 一個物件 + 兩個字串
多出原始資料沒有的欄位 — UI 狀態、驗證結果
指標間接性造成碎片 — 物件散落 heap 各處，實際 RSS 高於理論加總

實務上 5–10× 是常見量級：460 bytes 的一列變成數 KB，100 萬列就是 460MB vs 好幾 GB。

要注意的對照：緊湊格式也會重複儲存同樣的字串（沒有 dictionary 壓縮），差距不在資料本身，全在包裝。

延伸：瀏覽器內 SQLite：把查詢下推到 Worker 的 WASM heap、WASM linear memory 是 GC 管不到的記憶體