模型吐到一半，畫面已經開始長卡片：那篇「半截 JSON」實戰指南，把前端圈的記憶都叫醒了

2026年10月18日，掘金作者「貓頭_」刊出一篇長文，標題問得相當具體：模型吐出半截 JSON，前端如何邊收邊渲染？文章自稱「通俗實戰版」，保留效能實測對比與原生 JS、Vue 3、React 三套可直接落地的程式碼，宣稱八分鐘能讀完。這類技術長文向來是開發者社羣的收藏熱區，這篇也不例外。

先把場景擺出來：白屏等 JSON 的那十幾秒

做普通 AI 聊天時，模型輸出的是純文字或 Markdown，前端收到一個字就往畫面追加一個字，打字機效果自然成立。但越來越多功能要求模型直接回傳 JSON 結構化資料，讓前端渲染成互動元件。文章列了幾個典型場景：

• 商品或知識卡片：標題先跳出來，摘要逐字填充
• 流式資料表格：一行接一行長出來
• 智慧表單填充：表單項逐個自動回填
• Agent 工具呼叫：工具參數天生就是半截 JSON 碎片

問題在於，模型生成一段完整 JSON 往往需要幾百個 Token、耗時五到十五秒。如果傻等到最後一個大括號才呼叫 JSON.parse，使用者就得對著白屏乾等十幾秒，流式傳輸也就失去了意義。這個畫面前端工程師太熟悉了，大概是這篇文章能被轉發的第一個原因。

兩層 JSON 別混為一談

文章接著點出一個新手常見的混淆：在 SSE 流式接收時，不是已經用 buffer 處理過半截 JSON 了嗎？作者的答案是，流式結構化輸出裡其實有兩層完全不同的 JSON。

外層是 SSE 傳輸信封，一行一條，幾毫秒就能湊齊，收到換行符就能解析。內層才是本文主角：把所有 delta.content 拼起來的業務 JSON，要等模型吐完最後一個 Token 才完整，耗時可能長達幾十秒。前一層用 buffer 按行切就行，後一層不能乾等，必須把半截字串臨時補全成合法 JSON。

而瀏覽器原生的 JSON.parse 是全有或全無的嚴格解析器，末尾少一個引號或括號就立刻拋出 SyntaxError，不會把已經解析好的欄位還給你。這正是整個題目的核心難點。

這與先前那篇Markdown 流式解析面試題討論的處境幾乎同源：模型輸出永遠是碎片，前端卻被要求即時給出完整畫面。

三關闖過去，全鏈路才通

文章把解法整理成三關：第一關協議剝殼，從 SSE 信封取出 content 碎片；第二關結構補全，把半截字串補成合法 JSON；第三關平滑渲染，按幀節流加預設值兜底加防閃爍。

從來源可見的部分，文章還包含跨框架程式碼與效能實測對比，宣稱長表格首屏等待時間可縮短八成。此一數字屬作者方說法，實際效果自然得看各自專案的資料量與渲染條件，本文先照實轉述、保留查證空間。

為什麼這種文章年年有人寫、年年有人讀

把幾件事並排放在一起看，味道就出來了。模型輸出變快、結構化輸出變成標配，前端的「即時感」反而成了新的工程債。從 Markdown 流式渲染到半截 JSON 補全，題目換了殼，核心都是同一件事：如何在資料還不完整的時候，就給使用者一個看起來完整的畫面。

「貓頭_」這篇的賣點在於把問題拆得夠白話，又附了三套框架可直接抄的程式碼。對正在做 AI 功能的前端來說，這種文章的價值不在理論，在於明天上班就能用。至於裡面的補全策略在極端巢狀結構下會不會失效、防閃爍的取捨怎麼拿捏，就得等更多實戰回饋進入留言區了。