前幾天，Next.js 15 正式發布了。然后我就馬不停蹄的通過重構一個項目去感受 Next.js。

整體使用下來的感覺是，要用好 Next.js 的難度更高了。

這里最核心的兩個原因，一方面是底層支持了 React 19，未來會成為主流的開發方式。另外一方面是 App Router 的重要性進一步被官方團隊強調，經過一年多的持續預熱和強推，Page Router 到 App Router 的升級已經成為了不可逆的趨勢。

一、React 19

實際上在這個時間節點，React 19 還沒有正式發布，他目前還只是 RC 版，但是，Next.js 的默認項目中，已經直接使用 React 19 RC 了。

React 19 的開發思維和之前的版本有很大的不同。其中最主要的影響，就是在底層代碼中，完全的、徹底刪除了 legacy 模式。

從 React 17 開始，React 中就存在兩種模式。

一種是傳統的 legacy 模式。我們可以暫且簡單粗暴的將其翻譯為同步模式。因為該模式下的大多數關鍵底層函數，都是基于 sync 來命名。例如 shceduleSyncCallback、performSyncWorkOnRoot 等等。

另外一種就是 Concurrent 模式。也就是我們聽到很多的并發模式。但是由于長期以來，對于并發模式的思考與支持并不成熟，因此在實際的開發中，有意識的使用并發模式來解決實際項目問題的團隊并不算多。因此，并發模式更多的出現在技術類文章里，或者面試里。實際上要怎么用他，許多團隊也還沒有一個非常明確的方向與感受。

當然，經過長時間的預熱與宣傳，并發模式到目前為止，已經形成了共識，在 React 19 中，legacy 模式的所有代碼，都被直接刪除。那么也就意味著，如果我們要用好 React 19，就必須要對并發模式有一個非常深刻的理解。

也正因為如此，許多項目要升級到 React 19 將會存在不少難度。當然，由于并發模式實際上已經過渡了很多年，許多團隊的項目本身就是直接基于 React 18 來開發，那么升級的難度會小很多。

除此之外，React 19 所提倡的開發模式，與之前的版本相比，也出現了很大的區別。

一種很重要的思路就是：我們需要盡可能的把 useEffect 變成一個非常小眾的 hook，只會偶爾使用一下。

這會讓許多 React 開發者感受到不適應。因此，在我的付費小冊《React 19 全解》中，我花了很大的篇幅來介紹 React 19 的細節，幫助大家能夠快速掌握這種新的開發思維。

?

小冊地址：usehook.cn

二、App Router

App Router 實際上也已經經歷了一兩年時間的預熱，但是通過群友的反饋來看，依然會有很多同學在使用他的過程中感覺不適應。

在 Next.js 15 中，App Router 變成了官方團隊主推的方案。這里最核心的是要重推 React Server Component【簡稱：RSC】

這就不是一個簡單的升級了，而是一次完全的變革。

開發者需要非常明確的區分客戶端組件與服務端組件。如果用得不好，你可能會發現你的項目里到處都是 use client，這樣不僅不能享受到 Next.js 給你帶來的提升，反而會感覺處處受到限制。

關于這個點，許多人會對 use client 的使用感到困惑的原因是因為，沒有理解到 use client 他代表的含義是：邊界，而不僅僅是標識當前組件是一個客戶端組件。

這里的邊界指的是，服務端與客戶端組件的邊界。我們只需要標識邊界，那么邊界之下的所有組件，都會自動變成客戶端組件，而不需要我們手動在每個組件中添加 use client。

當然，這里的上下級關系，指的并不是父子結點，而是文件引入的結構。

這帶來的一個強度很大的影響就是：對于使用者的組件合理拆分有很高的要求。這會讓許多的基礎使用者感覺到不適應。許多初中級開發者很難做到合理的拆分組件。

因此，他們會吐槽說，Next.js 的組件拆得太碎了，過度拆分等等。但是有的時候這種拆分是必須的，如果我們能夠合理的把服務端邏輯與客戶端邏輯處理好，對于項目的整體運行性能是非常有幫助的。這是 Next.js 追求的一個很重要的指標。

對組件的屬性問題分析不明確的話，經常會在開發中遇到報錯。因為服務端組件有非常多的 api 是不能使用的。如果你在編寫這個組件的過程中，并沒有思考該組件到底是 server 組件，還是 client 組件，你大概率會遇到很多報錯

當我們使用瀏覽器才存在的一些行為，例如點擊事件時，我們就必須使用 client 組件。這要求我們在開發階段，就要做好動靜分離，把點擊事件相關的邏輯單獨拆分出去重新封裝一個客戶端組件

三、SSG or SSR

這可能是很多人難受的一個比較重要點。因為在 App Router 中，有幾個重要的 API 消失了。他們就是

• 1、getStaticProps
• 2、getInitialProps
• 3、getServerSideProps

這些 API 的消失，會讓初學者很難清晰的判斷出來 SSG 與 SSR 的界限在哪里。例如，當我們想要提前獲取到頁面所需要的數據時，就使用 getStaticProps，這樣，頁面呈現所需要的數據，就可以在構建的時候獲得

這幾個 API 存在的好處就是，頁面到底是 SSG 還是 SSR，是由開發者來控制的。

但是在 App Router 中，邏輯大變。

開發者不再需要去區分我到底需要渲染成什么 SSG 還是 SSR。

如果我們要切換到動態渲染內容，那么可能需要通過調整緩存策略來實現。如下圖所示

這造成的結果是，可能我們寫的代碼大多數都會被渲染成 SSG，而當我們需要一些動態生成的頁面【SSR】，就進一步要求我們對每個動態 API 有深刻的理解。

學習成本變得更高了。

但是我個人更喜歡這樣的方式。因為在實際的開發中，我們發現，如果項目中存在大量動態渲染的內容，當訪問量規模變大之后，服務端的壓力會變得非常大，從而讓訪問速度變得更慢。因此，盡可能少的使用 SSR 是我在項目開發中的一個比較大的原則。

我會盡量把與具體用戶強關聯的展示信息放到客戶端組件中去處理。這里的前提是，經過分析發現，與客戶強關聯的內容大多數情況下都沒必要做 SEO。

四、總結

Next.js 15 發布之后，對三方生態庫來說，是一個巨大的挑戰。因為許多庫對 RSC 的支持并不是那么友好。因此在升級之前，大家一定要做好調研工作。評估好具體的風險與影響。

當然，新版本在開發體驗上的提升是非常明顯的，無論是構建速度，還是編譯速度，又或者是項目性能，都有非常明顯的提升。如果三方庫的影響是可控的，那么升級到新版本所帶來的收益非常大。