2025 年的 React，依然是前端圈里最受歡迎的框架，用戶群龐大、市場地位穩固。但與此同時，社區的氛圍卻變得微妙——質疑和分裂的聲音越來越多。

從 React Server Components（RSC）的落地困難，到 Vercel 影響力的爭議；從生態疲勞，到“官方推框架”的反感情緒，開發者們的討論正映射出 React 社區的深刻變化。

Vercel 的影響力爭議

“React 被接管了嗎？”

在不少討論里，最常見的一句話是：“React 已經被 Vercel 接管了。”

這種擔心并不是空穴來風：

?React 團隊里有多人加入了 Vercel；

?RSC 的設計和 Next.js 深度綁定；

?React 官方文檔里，把 Next.js 放在了最推薦的位置。

這讓很多人擔心，React 的方向會不會被一家公司的商業利益牽著走，失去開源的中立性。

商業動機的疑慮

進一步的爭議在于：

?React 的路線圖是否更多在服務商業需求？

?其他框架是否會因此處于不利位置？

?技術決策是否還能保持獨立和透明？

不過也有人認為，這其實是“因果倒置”。不是 Vercel 控制了 React，而是 React 的演進目標和 Vercel 的產品方向剛好契合。

RSC：承諾與現實的落差

技術復雜度超乎預期

RSC 本來被寄予厚望，說是能簡化 React 應用。可真正落地后，很多團隊卻發現：它讓項目變得更復雜了。

主要問題有：

?理解難：要同時考慮服務端和客戶端的執行環境，心智負擔陡增；

?場景有限：能真正發揮優勢的場景并不多，很多項目用不上；

?調試困難：現有調試工具在混合架構下不好使，開發體驗很差。

換句話說，RSC 并沒有帶來“更簡單”的開發體驗。

“單一實現”的困境

目前，Next.js 幾乎是唯一一個真正支持 RSC 的生產級框架。這讓不少人感到擔憂：

?會不會陷入對單一框架的依賴？

?其他框架跟進困難，生態創新被限制？

?老項目要遷移 RSC，需要巨大改造成本？

在很多人看來，RSC 更像是“Next.js 專屬功能”，而不是 React 社區的通用方案。

框架“強推”引發的反感

過去，React 的態度是“你可以選擇任何工具”。而現在，官方文檔里已經明確傾向于推薦全棧框架。

表現包括：

?把單頁應用（SPA）稱為“不尋常的約束”；

?用上了“我們無法阻止你”這樣的表述，讓人覺得帶點輕視；

?像 Vite 這樣的工具，被放在角落（后來因為社區爭議越來越大，React 最終妥協，添加了 Vite）。

問題是，社區需求本來就是多樣化的：

?初學者：框架反而加大了學習門檻；

?企業項目：受限于后端架構或合規要求，未必能引入全棧框架；

?小型項目：為了一個簡單頁面，卻要引入一整套重量級框架，顯得過度工程。

這種“一刀切”的推薦方式，自然會讓部分開發者覺得被忽視。

生態的疲勞感

React 的生態一度被人夸“選擇多”，現在卻成了讓人頭大的問題：

?選擇困難：路由、狀態管理、樣式方案……隨便一個環節都能挑出十幾種，選來選去浪費不少時間；

?升級焦慮：依賴更新太快，三個月前裝的庫現在可能就沒人維護了；

?技術債務：所謂的“最佳實踐”一年能換好幾次，項目被迫跟著不停重構。

不少人感嘆：React 已經很久不是當年那個“輕量、好上手”的工具了。

溝通上的問題

除了技術，大家對 React 團隊的溝通方式也頗有微詞：

?反饋經常遲遲沒人回應；

?一些重大決定沒有經過充分討論就直接拍板；

?團隊里也缺少專門做開發者關系的人。

更別提 RSC 了，官方文檔幾乎沒怎么解釋，絕大部分資料還是第三方寫的。結果很多人連最基本的問題都搞不清楚：RSC 到底是啥？能干嘛？適合什么場景？

開發者真正想要的

說到底，大家的訴求并不復雜，主要就三點：

1.簡潔：別讓心智負擔越來越重，能專心寫業務就好；

2.穩定：別讓版本、架構一年三變，學到的技能最好能用久一點；

3.清晰：把文檔寫完整，把路線圖說清楚，讓人知道該怎么走。

最后的想法

React 現在遇到的這些矛盾，其實是任何一個開源項目在做大之后都可能碰到的陣痛。

從最初的 UI 庫，到如今往全棧框架轉型，React 的復雜度肯定會上升，分歧也會越來越多。

未來能不能繼續穩住地位，就看幾個關鍵點：

?技術創新和社區團結之間怎么平衡；

?進步和穩定之間怎么取舍；

?商業力量和開源中立之間怎么畫界限。

React 依舊是前端領域最重要的玩家，但當越來越多開發者說出那句：“React 很好，只是它可能不再適合我。” ——或許就是現在社區真實的寫照。