Next.js 的應用要離開 Vercel，向來不是改一行設定就能解決的事。Cloudflare 在 2026 年 9 月 28 日發布了 Vinext 1.0，這個二月才從一場一週 AI 實驗誕生的專案，如今目標很明確：讓任何 Next.js 應用——不管是 Pages Router 還是 App Router——都能部署到 Cloudflare Workers 免費方案、Netlify 或 AWS Lambda。
相容性是靠測試堆出來的
Cloudflare 在公告中承認，初版 Vinext「有潛力但不完整」。這七個月最大的工作量不在加新功能，而在重現 Next.js 的行為。他們的說法很誠實：實作一個同名函式不難，難的是讓 revalidatePath 正確影響到渲染頁面、快取條目和後續請求。
目前客戶要求的主要功能，測試相容度大多已超過 99%。支撐這個數字的是兩層機制：數千個針對核心行為的測試，涵蓋兩種 router、開發與正式環境、Node 和 Workers 兩種部署目標；再加上每晚跑一次 Next.js 官方 e2e 測試套件，持續追蹤上游變更造成的回歸。
1.0 實際多了什麼
對正在評估要不要轉換的團隊，1.0 有幾個值得看的點：
- 混合應用支援：Pages Router 的長期用戶不用一次遷移完，兩種 router 可以共存，涵蓋 React Server Components、Server Actions、middleware 等。
- 完整頁面生命週期：建置時預渲染、靜態匯出、頁面層級 ISR，加上按路徑或 tag 的背景與按需重新驗證。
- 可觀測性不中斷：現有的 OpenTelemetry 和 Sentry 設定可直接沿用，在 Workers 上還能接上原生 observability。
遷移本身被做進框架裡：跑 npx vinext check 驗證相容性，再跑 npx vinext init 建置設定，原有的專案結構保留不動。
一個值得注意的取捨：Next.js 16 主推的 Cache Components（"use cache"）在 Vinext 目前只有有限支援。Cloudflare 說他們訪談的團隊大多沒在用它，也不視為遷移前提。如果你的專案已經深度依賴這個指令，這是 1.0 目前最明顯的缺口。
快取預熱把渲染搬出建置機器
我認為這次發布裡對架構決策最有影響的是 cache warming。傳統做法是在建置時用 generateStaticParams() 預渲染所有頁面，但一個有十幾萬個 URL 的網站，會花大量時間渲染那些根本沒人拜訪的長尾頁面，而建置機器無法預知哪些才是關鍵路由。
Vinext 1.0 的做法是把預渲染搬到 Cloudflare 網路上：先部署新版本到 0% 的正式流量，從該版本主動請求高流量頁面、填滿快取，然後才把部署推上線。上線那一刻，熱門頁面已經有暖好的快取可以回應。
這種「先部署灰度版本、驗證、再推廣」的模式，和我之前在 Worker Previews 那篇討論的環境隔離思路是一致的：/blog/cloudflare-worker-previews-agent-branch-isolation/。
維護本身也被自動化了
Cloudflare 在公告裡描述了一套持續運作的工具鏈：每天早上由 agent 審查 Next.js canary 的新 commit、抓 diff、開追蹤 issue；每晚重新跑相容性矩陣。當測試發現落差，agent 可以跨兩個程式碼庫定位變更、建重現案例、移植測試並提出修正。
他們形容這是「為開源打造的軟體工廠」。實際效果是把維護者的注意力收斂到真正需要人類判斷的問題上——也就是哪些 Next.js 行為該如何映射到 Vite。
對 builder 來說，務實的下一步很簡單：先跑 npx vinext check 看你的專案落在相容矩陣的哪個位置，特別確認有沒有用到 "use cache"，再決定這條路現在走不走得通。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。