沖刺規劃會上，這事兒發生了。

我們在估算一個小型營銷站：三頁內容，幾段文案，一個表單，也許再加個帶切換邏輯的價格表。典型的“快建站”。

一個初級同事抬頭問我：

“所以我們這次用 React 起個腳手架，對吧？”

我說：“不。服務器端渲染。”

他眨了眨眼，然后笑了。

“等下，你說……SSR？你是認真的？”

我當然是認真的。

對最近五年入行的一些前端來說，SSR 聽起來像是降級，仿佛我建議我們用 COBOL 寫完再丟到一塊樹莓派上跑。

我在前端這條路上繞過不少彎。經歷過“萬物 React 化”：一頁應用（SPA），水合地獄（hydration hell），為渲染六行文字卻要下發超大體積的 bundle。我親眼看著所謂“現代網站”為靜態內容都要起一層骨架屏。

所以，不，我不是開玩笑。我是終于認真了。

React 變成了“默認”，而不是“選擇”

先說清楚：我喜歡 React，也尊重它開啟的可能性。但某個時刻起，它從決策變成了默認。我們伸手去拿它，卻沒先問：我到底要解決什么問題？就像用電鋸開一封信。

以至于連營銷站（極其簡單、幾乎靜態、除了表單沒什么交互）都要攜帶兆級 JavaScript，只為給你看一個標題和一枚按鈕。

與此同時，真實的加載體驗呢？空白屏。轉圈圈。然后，也許——如果你運氣不錯——才出現內容。

服務器從沒“失靈”

于是我回到基本面：SSR，HTML 優先渲染，最小化 JS。我開始按“老辦法”做站——那種就是能用的辦法。

然后，猜猜發生了什么？

• 頁面更快出現；
• SEO 立刻生效；
• 沒有客戶端路由的詭異 bug；
• 不再出現水合不匹配；
• 不需要 300KB 的表單庫來校驗“姓名 + 郵箱”。

今年我們交付的一個項目（帶少量圖表的小儀表盤），從 3MB+ 的 React 及依賴，降到總資源不足 400KB；加載小于 1 秒；能離線；Lighthouse 98 分。沒有 React、沒有 Vite、沒有水合；只是 SSR，再用 AlpineJS 點綴必要的交互。

客戶的評價很簡單：“就是更快。”

而事實也是如此。

這不是“倒車”，而是重新思考

初級同事會笑，并不奇怪。行業這些年一直在對他們說：SSR 是遺物；客戶端優先才是正解；水合不可避免；SPA 是默認。

但大多數網站不是應用；而大多數應用，也不需要把大腦打包到瀏覽器。

SSR 是拒絕被復雜度綁架。

它提醒我們：服務器擅長渲染，瀏覽器擅長展示。展示一串列表，不需要 JS 框架；渲染幾段文本，不需要“整頁再水合”；當用戶只是想讀點東西時，更不需要造一整套 SPA。

讓服務器，干服務器該干的活

我當時就這么對他說：

“能在服務器渲染，就在服務器渲染。能發 HTML，就發 HTML。能避開水合，就避開。

然后——只在確實需要交互的時候，再小心地撒點 JS。別為了一個下拉開關，把整棟樓倒著蓋。”

這回，他沒笑。

最后的想法

SSR 是按 Web 的本意在做事：快速、韌性強。那種能立刻出現、迅速著色、就算 JS 失效也不至于崩掉的網站。

下次你出于習慣伸手去拿 React 的時候，先問一句：

“如果我不用它，會怎樣？”

也許，你會驚訝于自己并不懷念那些負擔。