我第一次掃 Nuxt 4.5 的 release note，看到 Vite、Rspack 和 SSR streaming 擠在一起，腦中只剩一句：「所以我到底要換哪一個？」後來才發現這問題本身就問錯了。前兩個在處理怎麼 build，最後一個在處理頁面怎麼送出去，把它們放在同一場速度競賽裡只會越看越亂。
Nuxt 4.5 同時帶來 Vite 8、由 Rsbuild 支援的 Rspack 2，以及實驗中的 SSR streaming。看起來名詞很多，可以先把它們分成兩類：前兩個負責建置，最後一個負責伺服器怎麼把頁面送給瀏覽器。
大多數 Nuxt 專案繼續使用預設的 Vite 就可以。Rspack 比較適合需要 webpack 相容性，或團隊本來就有相關設定的情況。選擇不是看哪個名字比較新，而是專案依賴能不能正常配合。
SSR streaming 則讓伺服器不必等整頁內容都準備好才回傳，可以先送出已完成的部分。它對資料來源較多的頁面比較有感，也仍要配合 loading 狀態，才不會讓內容出現得很零碎。
這三項更新放在同一版有點像 Nuxt 同時處理「怎麼打包」和「怎麼送頁面」。前者多半由框架替我們決定，後者會直接影響 UI。使用 streaming 時，設計 loading skeleton、避免 layout shift，反而比記住底層名詞更貼近日常工作。
如果網站頁面很單純、資料一次就能拿完，streaming 不一定帶來明顯好處。它比較適合有快慢不同資料來源的頁面，先讓導覽和主要內容出現，再補上等待較久的區塊。
我會先用瀏覽器的 Network 和 Performance 看目前到底卡在哪。若時間都花在一個必須完成的 API，換 bundler 或開 streaming 都不會憑空讓資料變快；比較有機會的是把不相依的區塊拆開，讓慢資料不要擋住標題和導覽。
Rspack 則應該由相容性需求拉動，而不是拿來和 Vite 辦賽跑。專案如果沒有 webpack 歷史包袱，預設路徑通常最省維護；真有 loader 或大型既有設定，再做一個代表性頁面的 build 比較，答案會比宣傳數字可靠。