2018 年，React 團隊首次“劇透” Suspense 時，許多人以為這將是下一次大飛躍。

一個能讓組件在數(shù)據(jù)未就緒時暫緩渲染的能力？

聽起來就像魔法。

然而，一年又一年，Suspense 始終停留在實驗階段。 開發(fā)者反復(fù)追問：“什么時候穩(wěn)定？我們究竟何時能放心用？”

到了 2025 年，Suspense 終于隨 React 穩(wěn)定特性一并發(fā)布，算是正式“發(fā)貨”。

問題隨之而來：六年等待，值得嗎？

Suspense 到底在做什么？

本質(zhì)上，Suspense 允許組件在“等待某件事”時暫停渲染——典型場景就是等數(shù)據(jù)。

與其在各個角落手寫 loading 狀態(tài)，不如聲明式地標注哪些 UI 可以暫停，以及應(yīng)該展示怎樣的回退（fallback）。

示例（經(jīng)典 loading UI）：

?? 示例（使用 Suspense）：

此時，Profile 組件可以自行拉取數(shù)據(jù)，React 負責(zé)在就緒前渲染 fallback。思維方式也隨之轉(zhuǎn)向：從“處處命令式地處理加載”，到“在合適的邊界上聲明 UI 可以 SUSPEND”。

為何要等這么久？

因為 Suspense 不是一個普通的 Hook，而是牽動了底層架構(gòu)的改造：

• 并發(fā)渲染（Concurrent Rendering） → React 需要能安全地暫停與恢復(fù)渲染。
• 流式 SSR（Streaming SSR） → 數(shù)據(jù)要分塊抵達而非“一次性到位”。
• 與框架協(xié)同 → Next.js、Remix 等生態(tài)需要與之對齊整合。

簡而言之：為了讓 Suspense 成立，React 必須重塑自身的部分機制。

這就是它拖了六年的根本原因。

2025 的落地場景：它真正發(fā)光的地方

1) 與 Server Components 結(jié)合的數(shù)據(jù)獲取

Suspense 與 React Server Components（RSC） 是天作之合。數(shù)據(jù)在服務(wù)器側(cè)獲取，JS 體積更小；Suspense 邊界決定哪些內(nèi)容先流給客戶端、哪些稍后補齊。因此，你得到的是“少腳本、快首屏、流式拼接”的三贏。

2) 漸進式渲染（Progressive Rendering）

借助 Suspense，可以先渲染可用部分，讓重量級組件“掛起”直至就緒。于是你不再被“一塊空白屏”綁架，與此同時用戶始終“看得到點什么”。

3) 更貼合人的體驗設(shè)計

不必到處堆“旋轉(zhuǎn)菊花”。按照區(qū)域設(shè)計精細的回退，就地交付感知；用戶得到即時反饋，而不是被迫盯著全局“l(fā)oading...”頁發(fā)呆。

值不值？——“是”，但要看你在造什么

對于嚴肅應(yīng)用：答案更傾向于 Yes。

Suspense 讓應(yīng)用更快、更整潔、更好維持；它解決了過去手寫加載邏輯的痛點與脆弱。

但要注意：

• 如果你只是在做一個小型 SPA，Suspense 可能顯得殺雞用牛刀。
• 它在 Next.js 13+ 等框架里更耀眼——RSC 與流式特性已經(jīng)內(nèi)建。
• Suspense 從來不是“換個 Spinner 就完了”的替代品；它要你重新思考“渲染 + 取數(shù)”的方式。

參考：React 官方文檔 — https://react.dev/reference/react/Suspense

六年很久，基礎(chǔ)更久

確實，有的開發(fā)者失去了耐心；也有人轉(zhuǎn)向 Solid、Qwik 等更早交付相近理念的框架。盡管如此，隨著 Suspense 進入穩(wěn)定軌道，React 至少證明了：“慢工出細活”的路徑，未必輸在起跑線，往往贏在地基。

所以，值不值？

?? 如果你在 2025 年打造嚴肅、數(shù)據(jù)密集的應(yīng)用，答案是：非常值得。

React 的未來是 Suspense + Server Components，而且這一次，它不再只是預(yù)告，而是終于落地成真。