線上 JSON 編輯器處理 20MB Base64 效能評測：為何會卡頓？

日常開發中，當我們透過線上 JSON 編輯器解析 API 回應時，通常都期待它能秒開。然而，當資料中夾帶了來自現代 AI 或多媒體 API 的 20MB Base64 圖片字串時，幾乎所有工具都會陷入極度卡頓。頁面失去回應、捲動卡死，整個編輯器幾乎直接癱瘓。

這到底是怎麼回事？是硬體效能不足，還是瀏覽器在處理超長文字時有根本性的缺陷？我們決定用一台高規格開發機來做一次橫向評測，找出目前主流格式化工具在高壓下崩潰的確切原因，並提出解決方案。

20MB 基準測試：主流線上 JSON 編輯器橫向評測

為了排除硬體效能不足的干擾，我們直接在一台旗艦級開發機上進行測試：

• CPU: Intel Core i7-14700F
• 記憶體: 32GB RAM

我們撰寫了一支 Playwright 腳本，模擬將 1MB 到 20MB 的 JSON 資料貼入幾款主流格式化工具中。您可以從 GitHub Gist 取得該腳本來自行重現或修改測試。以下是實測結果，重點關注載入（Load）耗時（括號內為格式化與壓縮耗時）：

為什麼線上 JSON 編輯器面對超大 Base64 字串會卡死？

這種巨大的效能落差凸顯了傳統 Web 應用在處理語法高亮時的嚴重限制。當線上 JSON 編輯器在大型 Base64 資料上嚴重卡頓時，本質上是碰到了以下兩個主要瓶頸：

1. 單執行緒 CPU 瓶頸

瀏覽器中的 JavaScript 執行是單執行緒的。當傳統的格式化工具收到一份 20MB 的檔案時，會在主執行緒上跑極為繁重的語法分詞與排版計算迴圈。由於它無法將工作分配給多個 CPU 核心，即便配備了 i7-14700F 這樣的多核處理器也無濟於事。單核直接被打滿到 100%，頁面徹底失去回應，連捲動都做不到。

2. 超長單行文字的渲染瓶頸

在解析大型檔案時，語法高亮工具會將整段 Base64 字串包進一個 <span class="string"> 節點中。真正的瓶頸在於：這個節點包含了約 2,700 萬個字元，而且全部擠在同一行上、沒有任何換行符號。編輯器的核心引擎必須為這行「超級單行」逐字元量測寬度、計算可能的換行位置以及游標定位。對於如此巨大的連續字串，這些排版計算會導致災難性的記憶體暴增，直接鎖死瀏覽器的主執行緒（Main Thread）。

ViewJSON 的解法：媒體替換與無損剪貼簿

傳統編輯器卡死的根本原因，在於它們試圖把數千萬個字元硬生生渲染出來。但我們發現了一個核心事實：開發者在貼上 20MB 的 Base64 亂碼時，壓根不打算閱讀這段程式碼，而是想看它背後的實際圖片或媒體檔案。基於這個洞察，ViewJSON 放棄了硬撐瀏覽器的物理渲染極限，改從產品體驗層面進行底層架構設計：

• 媒體替換（而非單純截斷）: 當 ViewJSON 偵測到 Base64 字串時，會解碼魔術位元組（Magic Bytes），並直接用真實的行內媒體預覽（如圖片）取代那段無法閱讀的程式碼區塊。若使用者關閉預覽模式，也會對超長字串進行智慧截斷。無論哪種模式，都阻止了數以百萬計的字元進入編輯器的文字緩衝區，徹底釋放核心引擎與渲染執行緒的運算負擔。
• 無損剪貼簿復原: 隱藏原始文字通常會帶來一個致命問題：複製 JSON 時拿到的是殘缺資料。ViewJSON 透過自訂剪貼簿管理器解決了這個問題。無論畫面上顯示的是圖片預覽還是截斷後的文字，只要按下「複製」，編輯器就會在背景自動還原完整的原始 Base64 資料，確保複製出來的內容 100% 完好無損。

正是這種「規避渲染」與「資料完整性」的結合，使 ViewJSON 能在兩秒以內極速格式化 20MB 的超大 JSON 資料。