遷移 Remix 至 Next.js

為什麼 Remix 團隊正在遷移至 Next.js

Remix 有明確的身份：伺服器優先的 React，在單一路由文件中共置 loaders、actions 和 UI。然後 Shopify 收購了它。然後它合併到 React Router。現在它是 React Router 7 搭配「框架模式」——一個品牌重塑，讓數千名開發者困惑於他們究竟在基於什麼構建。

React Router 7 過渡引入了套件重組（@remix-run/* → @react-router/*）、配置文件變更、組件重命名（RemixServer → ServerRouter、RemixBrowser → HydratedRouter）和破壞性的型別系統變更。對許多團隊來說，這是轉向具有更清晰路線圖的框架的最終信號。

Next.js 正是這樣的框架。憑藉 App Router、React 伺服器組件、Server Actions 和 Vercel 的支持，Next.js 提供了 Remix 承諾的一切——加上 ISR、邊緣渲染和最大的 React 框架生態系統。

React Router 7 的問題

讓我們直言不諱地談論發生了什麼。Remix v2 是一個穩固的框架。與 React Router 7 的合併創造了真正的問題。

身份危機

它是路由器還是框架？React Router 7 提供三種模式：聲明性路由、數據路由和框架模式。框架模式本質上是重新品牌的 Remix，但試著向第一次閱讀文檔的新員工解釋這一點。社區在使用它作為 SPA 路由器的人和使用它作為全棧框架的人之間分裂。

生態系統不確定性

@remix-run/* 套件已棄用。遷移指南存在，但它們是機械性的——交換套件名稱、重命名組件、更新類型。它們沒有回答的是這個平台在 18 個月內是否會再次經歷身份轉變。RSC 支持「即將推出」但仍未發布。Next.js 自 13 版本以來就有穩定的 RSC。

市場份額萎縮

Stack Overflow 答案、教程內容、招聘池——Next.js 在所有方面都佔據主導地位。找 Next.js 開發者很直接。找到深刻理解 React Router 7 框架模式的人？那是一個小得多的池子。

Next.js 給你什麼

從 Remix 遷移到 Next.js 不是重寫。兩個框架都是 React。你的組件、hooks 和 UI 庫基本上保持不變。真正的遷移工作在於數據獲取模式和路由約定。

預設伺服器組件

Next.js App Router 組件預設是伺服器組件。沒有特殊語法，沒有 loader 函數——只是直接獲取數據的 async 組件。對於唯讀頁面，這比 Remix 的 loader 模式更簡單。

// Remix loader 模式
export const loader = async () => {
  const posts = await db.posts.findMany();
  return { posts };
};

export default function Posts() {
  const { posts } = useLoaderData<typeof loader>();
  return <PostList posts={posts} />;
}

// Next.js 伺服器組件
export default async function Posts() {
  const posts = await db.posts.findMany();
  return <PostList posts={posts} />;
}

更少的抽象。更少的導入。數據正好位於組件所在的位置。

Server Actions 替換 Form Actions

Remix 的表單變更 action 導出清晰地映射到 Next.js Server Actions。心智模型相似——伺服器端變更函數——但 Server Actions 更可組合。它們可以跨組件工作，不僅限於路由級別。

// Next.js Server Action
'use server';

export async function updateProfile(formData: FormData) {
  const name = formData.get('name');
  await db.users.update({ where: { id: userId }, data: { name } });
  revalidatePath('/profile');
}

渲染靈活性

Remix 給你一種渲染策略：伺服器優先。Next.js 給你 SSG、SSR、ISR 和邊緣渲染——每個路由都有。行銷頁面可以以靜態方式生成並使用 ISR 每 60 秒重新驗證，而你的儀表板流式傳輸伺服器渲染的數據。這種靈活性直接影響性能和託管成本。

邊緣就緒基礎設施

部署到 Vercel 的邊緣網絡，你的 TTFB 全球下降到低於 100ms。Remix 可以在 Cloudflare Workers 上運行，但 Next.js on Vercel 是現成的——沒有自訂伺服器設置，沒有適配器配置。

我們的遷移流程

我們遷移了從 20 路由行銷網站到 200+ 路由 SaaS 平台的 Remix 應用。以下是我們完善的流程：

第 1 階段：審計和架構（第 1 週）

我們映射每個 Remix 路由、loader、action 和錯誤邊界。我們確定哪些頁面應該是靜態的（SSG/ISR）、哪些需要伺服器渲染，以及哪些需要客戶端互動。我們還審計你當前的 Lighthouse 分數、核心網絡生命值和索引 URL 來建立基線。

第 2 階段：基礎設置（第 1-2 週）

我們搭建 Next.js App Router 項目、配置 TypeScript、連接你現有的樣式解決方案（Tailwind、CSS Modules、styled-components），並在 Vercel 或你偏好的主機上設置部署管道。

第 3 階段：路由遷移（第 2-4 週）

這是大部分工作。每個 Remix 路由文件被分解：

• Loaders → 伺服器組件，直接獲取數據，或 generateStaticParams + fetch 用於靜態頁面
• Actions → 專用 actions.ts 文件中的 Server Actions
• 錯誤邊界 → Next.js error.tsx 約定
• Meta 函數 → Next.js generateMetadata
• Links → Next.js <Link>（API 幾乎相同）
• 嵌套佈局 → Next.js layout.tsx 文件（這映射得很清晰，因為兩個框架都使用嵌套路由）

React 組件很少需要除了導入路徑以外的變更。你的 <Button>、你的 <Card>、你的自訂 hooks——它們都直接轉移。

第 4 階段：SEO 保留（第 4-5 週）

這一步不是可選的。我們實施：

• 301 重定向適用於每個改變結構的 URL，在 next.config.js 中配置
• XML 站點地圖生成，經由 app/sitemap.ts
• 規範 URL 在每一頁上
• 結構化數據（JSON-LD）遷移
• OpenGraph 和 Twitter 卡片元數據，經由 generateMetadata
• Google Search Console 監控，用於啟動後的爬蟲錯誤

我們處理過零排名頁面丟失的遷移。關鍵是重定向映射和元數據奇偶性——我們驗證每個索引 URL 都有對應的目標。

第 5 階段：QA、性能和啟動（第 5-6 週）

在切換 DNS 之前，我們運行完整的 Lighthouse 審計、跨瀏覽器測試和負載測試。啟動後，我們監控核心網絡生命值和 Search Console 兩週以盡早發現問題。

時間表和定價

30 個路由以下的小型 Remix 應用通常在 3-4 週內遷移，起價 $8,000。中等規模應用（30-100 個路由）需要 5-8 週，費用為 $15,000-$30,000。具有複雜數據模式、身份驗證和廣泛 API 集成的企業 Remix 平台需單獨範疇。

每項合作都以免費遷移審計開始。我們將審查你的 Remix 程式碼庫、確定遷移複雜性，並在 48 小時內提供固定價格提案。

底線

Remix 是一個很棒的框架。React Router 7 最終可能會站穩腳跟。但目前，Next.js 擁有生態系統、工具、部署基礎設施和生產應用所需的社區動力。如果 React Router 品牌重塑讓你的團隊質疑你的堆棧未來，那個本能值得採取行動。