線上工具支援多大的 JSON 檔案
結論：沒有統一上限，真正卡住你的是瀏覽器分頁的記憶體預算：一份 20MB 的 JSON 解析後通常膨脹到 60–100MB，再疊加渲染節點，幾百 MB 就崩了。
結論：沒有統一上限，先按記憶體估算——解析後的物件通常是原文字的 3–5 倍，還會疊加高亮 DOM；超過 50MB 或頂層筆數幾十萬時，改用分片查看、串流解析或本機客戶端，別在瀏覽器分頁裡硬扛。
記憶體怎麼被吃掉的
一份 20MB 的 JSON 文字進入頁面後，會同時存在三份：
- 原始字串：20MB
- 解析後的物件樹：通常 60–100MB（字串重複儲存、物件標頭開銷、雜湊表）
- 格式化後的高亮 DOM：每個 token 一個節點，容易再翻一倍
還沒算編輯器緩衝區、復原堆疊、語法高亮的中間結果。所以「20MB 檔案」在記憶體裡可能是 200MB 以上。
實測經驗值
| 檔案大小 | 桌面瀏覽器 | 行動裝置 |
|---|---|---|
| < 5MB | 順暢 | 順暢 |
| 5–20MB | 略有卡頓，格式化需 1–3 秒 | 明顯卡頓，可能無回應 |
| 20–50MB | 可用但吃力，建議關閉高亮 | 大概率崩潰 |
| > 50MB | 不推薦 | 不可用 |
數值會隨裝置、瀏覽器版本、是否開啟語法高亮浮動，用來看量級而不是當硬指標。
為什麼不是「加記憶體就行」
瀏覽器給單一分頁的記憶體有上限，而且超限是直接崩潰（Aw, Snap），不會優雅降級。手機上更嚴格，通常幾百 MB 就觸發回收。
大檔案怎麼辦
方案一：分片查看。 只取前 N 筆記錄格式化：
head -c 1048576 big.json | jq . # 只看前 1MB
jq '.items[0:100]' big.json # 只看前 100 筆
方案二：串流解析。 用 stream-json、ijson、jq --stream 逐筆處理，記憶體佔用與檔案大小無關。
方案三：本機客戶端。 桌面應用不受分頁限制，能利用全部記憶體：桌面端下載。
方案四：換格式。 如果是日誌、事件流，本來就不該用單個大 JSON，改 NDJSON 一行一筆，天生可串流。
方案五：讓後端裁剪。 前端只需要三個欄位時，介面就該只回三個欄位。很多「大檔案」問題本質是介面設計問題。
判斷自己的檔案屬於哪一檔
ls -lh data.json # 看體積
jq 'length' data.json # 看頂層是陣列還是物件、有多少筆
如果 length 是幾十萬，那不管多大都該考慮分頁或串流，而不是想辦法在前端硬扛。
常見問題
如何判斷自己的檔案屬於哪一檔？
先用 ls -lh 看體積、用 jq 'length' 看頂層筆數。幾 MB 以內任何裝置都順暢，20–50MB 在桌面瀏覽器還能處理但會明顯卡頓，超過 50MB 就該改用串流解析或命令列工具。
檔案超過 50MB 應該怎麼處理？
優先分片查看或串流解析，用 head -c 配合 jq、stream-json 或 jq --stream 逐筆處理，記憶體佔用與檔案大小無關。資料必須整體檢視時改用桌面客戶端，不受瀏覽器分頁記憶體限制。如果檔案本身是日誌或事件流，改 NDJSON 更合適。