Nuxt 4 公布時，我先做的不是看新功能，而是找 migration guide。沒辦法，穩定運作的專案看到 major version，第一反應通常不是興奮，是「這次又要壞哪裡」。讀完之後倒有點意外：它沒有硬塞一套全新哲學，比較像把 Nuxt 3 住了幾年後散落滿地的東西重新收進櫃子。
Nuxt 4 比較重大的更新
-
新的
app/目錄：pages、components、composables等前端程式集中在app/，和根目錄設定、server/程式分開。專案愈大，這種邊界愈有價值。 -
TypeScript 專案拆分： app、server、shared 與 builder 使用各自的 TypeScript context，再由根目錄設定統整。好處是瀏覽器型別不會隨便跑進 server，反過來也一樣。
-
useAsyncData與useFetch行為整理： 相同 key 會共享 ref，資料沒有使用者時能清理，也支援 reactive key 和更細的 cache 控制。它不是新 API，卻會影響既有頁面的資料更新方式。 -
開發與 CLI 效能改善： 編譯快取、原生檔案監看和內部 socket 等調整，主要目標是縮短啟動與開發等待。這些是底層更新，理想狀況下不需要專案特別改寫。
-
清除相容層和棄用項目：
@nuxt/kit移除 Nuxt 2 相容，部分舊行為也正式收掉。一般頁面未必受影響，老 module 和深度客製設定則要特別確認。
升級時我會怎麼排順序
先在 Nuxt 3 的最後階段處理 console 警告，再列出實際依賴的 modules，確認它們是否標示支援 v4。接著才升框架並跑 typecheck、build 和主要頁面流程。目錄搬到 app/ 可以另外做，不需要和所有變更擠在同一個 commit。
舊目錄仍向下相容，所以沒有必要為了看起來像 Nuxt 4 就立刻搬完。反而是資料請求共享、快取和 hydration 行為值得多看一眼；畫面能打開，不代表 client navigation 後的資料一定和以前完全相同。
我的看法
我喜歡這種「整理房間式」的 major release。新目錄和 TypeScript 邊界不會出現在產品截圖裡，卻能減少專案做大後的混亂。缺點是它看起來不夠戲劇化，很容易被誤認成只有改資料夾。
對既有專案來說，最穩的做法是把框架升級、module 相容與目錄搬移拆開處理。一次只改一類問題，真的出錯時才知道要往哪裡找。
我還會特別錄一輪升級前的 navigation 行為：同頁重複請求、返回上一頁、快速切換參數，以及 hydration 後第一次操作。資料層的 breaking change 常不是頁面直接白掉，而是第二次進入時拿到舊 ref，這種問題只跑一次 build 很難發現。
至於 app/，我會把它當成團隊邊界，而不是 Nuxt 4 的打卡任務。等新功能先照新目錄放，舊功能在被修改時再搬，git history 和 review 都會乾淨許多。