🔧 阿川の電商水電行

Shopify 顧問、維護與客製化

💡

小任務 / 單次支援方案

單次處理 Shopify 修正／微調

⭐️

維護方案

每月 Shopify 技術支援 + 小修改 + 諮詢

🚀

專案建置

Shopify 功能導入、培訓 + 分階段交付

👉 瞭解詳情 / 免費諮詢

小編精選 - 技術文章翻譯 · 02月17日

Next.js 終於有競爭對手了。

Next.js 讓 React 變得簡單易用。 TanStack Start 讓 React 重新煥發了 React 的活力。

如果你正在為2026年2月的一個實際專案選擇一個框架，那麼這篇文章正是我夢寐以求的。它不是功能矩陣，也不是那種「兩者都很好」的敷衍詞。我已經為你做了研究，省去了你重複勞動的麻煩。每個資料都有來源，每個論斷都可驗證。讀完之後，你就能清楚知道該選擇哪個框架，而最終的選擇會根據你建造的專案而有所不同。

Next.js 16.1.6。 TanStack Start 1.159.5 RC。截至今日的最新版本。

五年方案已經失效

五年來，答案只有一個。有人問“我該用哪個 React 框架？”，你就說 Next.js。會議結束。

那個答案之所以有效，是因為它確實如此。 Next.js 提供了基於檔案的路由、伺服器端渲染、映像優化，以及流暢到近乎完美的部署體驗。 Vercel 開發了框架，Vercel 負責託管，使用者體驗也棒極了。你發布了，它執行正常，然後你就可以繼續你的生活了。

2023 年，App Router 取代了 Pages Router，React 伺服器元件成為預設的思維模式。除非你選擇使用"use client" ，否則每個元件都會自動成為伺服器元件。伺服器操作允許你在前端檔案中編寫後端邏輯。底層自動運轉著三個獨立的快取層。其前景令人矚目：更少的 JavaScript 程式碼被傳送到瀏覽器，更快的頁面載入速度，更簡單的資料取得。

但事實並非如此。

GitHub 上有一個名為「有了新的 App Router，人們是否到處都用『use client』？」的討論帖，自 2023 年以來一直開放，直到 2026 年仍然有人在評論。最常見的抱怨並非伺服器元件無法正常運作，而是開發者無法預測程式碼何時在伺服器端執行，何時在瀏覽器端執行。這兩個環境之間的界線在出現問題之前是隱形的。

Next.js 16 修復了快取問題。現在所有動態程式碼預設都在請求時執行。您可以使用新的"use cache"指令明確啟用快取。這相比之前令人困惑的隱式快取機制有了巨大的改進。值得稱讚的是：Vercel 聽取了用戶回饋，並解決了這個最大的痛點。

但架構上的矛盾依然存在。你的應用程式被拆分成兩個執行環境，你需要負責管理它們之間的邊界。有些開發者在這種模式下如魚得水，而有些開發者則花費大量時間來除錯序列化錯誤，而不是開發新功能。

同時，在猶他州，一位從事家具製造的開源開發者卻有不同的想法。

React 歷史上被大眾廣泛採用的獨立開發者

Tanner Linsley 開發了 React Query。這個函式庫用 5 行useQuery程式碼就取代了你 200 行的 Redux saga，而且運作順暢。在 React Query 出現之前，在 React 中管理伺服器狀態是個棘手的問題，整個團隊需要花費數週時間才能勉強解決。而 React Query 的出現徹底解決了這個問題。它每週下載量高達 1200 萬次，並被蘋果、谷歌、Netflix、亞馬遜和沃爾瑪等公司廣泛使用。

React Table、React Virtual 和 TanStack Router 都出自同一人之手。 TanStack Router 悄悄成為 React 生態系統中最安全可靠的路由工具。他參與了 13 個開源專案，在 GitHub 上獲得了 112,660 個 star，總下載量超過 40 億次。 130 萬個程式碼庫依賴他的程式碼。

兩年前，他全心投入開源專案，組建了一支由 36 位貢獻者組成的團隊，並為他們提供充足的資金。他的專案發布速度之快，對於一個獨立專案來說幾乎是不可能實現的。

TanStack Start 是他開發的全端 React 框架，基於 TanStack Router 和 Vite 建置。其理念很簡單：程式碼應該清楚說明哪些功能在哪裡執行，類型定義應該在執行時之前捕獲錯誤，而且執行 React 應用程式不需要每月花費 500 美元的託管平台。

它目前仍處於候選發布階段。這一點很重要，我會詳細解釋原因。

程式碼揭示了真相

以下是 Next.js 16 中的一個儀表板頁面：

// app/dashboard/page.tsx
export default async function Dashboard() {
  const stats = await db.getStats()
  return <StatsView data={stats} />
}

簡潔高效。此元件直接從伺服器取得資料。沒有載入狀態，沒有 useEffect，也沒有狀態管理。元件本身就是資料層。這才是伺服器端元件的精髓所在，也是開發者體驗的真正提升。

但現在你的總理說儀錶板需要一個篩選按鈕。

您無法在此文件中新增useState 。伺服器元件不支援鉤子。因此，您需要建立一個新文件：

// app/dashboard/stats-view.tsx
'use client'

import { useState } from 'react'

export function StatsView({ data }) {
  const [filter, setFilter] = useState('all')
  const filtered = data.filter(d => filter === 'all' || d.type === filter)
  return (
    <>
      <button onClick={() => setFilter('revenue')}>Revenue</button>
      <DataTable rows={filtered} />
    </>
  )
}

每次useState ，都需要一個單獨的檔案、一條"use client"指令，以及對序列化邊界的理解。 data data從伺服器端傳遞到客戶端，這表示它被序列化為 JSON，因此你不能透過它傳遞函數、日期、映射、集合或類別實例。如果你的統計物件包含一個日期字段，它會以字串的形式傳遞。如果它包含一個方法，那麼該方法就會遺失。

你的應用程式互動性越強，有"use client"的檔案就越多，伺服器元件實際提供的幫助就越少。對於內容豐富但互動性極低的頁面來說，這種模型非常出色。但對於儀錶板、管理面板、資料密集型應用程式呢？你與其說是利用了架構的優勢，不如說是在與架構奮戰。

TanStack Start 中的同一頁面：

// routes/dashboard.tsx
import { createFileRoute } from '@tanstack/react-router'
import { createServerFn } from '@tanstack/react-start'
import { useState } from 'react'

const getStats = createServerFn({ method: 'GET' })
  .handler(async () => {
    return db.getStats()
  })

export const Route = createFileRoute('/dashboard')({
  loader: () => getStats(),
  component: Dashboard,
})

function Dashboard() {
  const stats = Route.useLoaderData()
  const [filter, setFilter] = useState('all')
  const filtered = stats.filter(d => filter === 'all' || d.type === filter)

  return (
    <>
      <button onClick={() => setFilter('revenue')}>Revenue</button>
      <DataTable rows={filtered} />
    </>
  )
}

只有一個文件。伺服器函數已明確聲明。這個元件是一個普通的 React 元件，可以使用任何它需要的 hook。沒有不可見的邊界。當頁面載入時，載入器會在伺服器上執行getStats() ，載入結果，然後元件從一開始就以完整的互動性渲染。

你無需考慮執行環境。伺服器函數會在伺服器端執行，因為你已經指定了。其他所有程式碼都會在 React 執行的地方執行。由於沒有任何隱藏程式碼，所以無需除錯。

現在來談談沒人寫的部分：TypeScript 使用體驗。

在 Next.js 中，從版本 15 開始，動態路由中的params以Promise<{ id: string }>的形式存在。搜尋參數是無類型的字串。例如，如果你的路由是/users/[id] ，而用戶存取的是/users/abc但你的程式碼期望的是一個數字，那麼在執行時就會發現問題。

在 TanStack Start 中，路由參數會根據檔案路徑推斷，並在路由層級進行驗證。搜尋參數則會獲得完整的 Zod 驗證。如果你的載入器期望params.id為數字，TypeScript 會在編譯時捕獲string 。如果你的搜尋參數需要?page=number&sort=string ，你只需定義一次模式，所有讀取這些參數的元件都會自動獲得自動完成、驗證和錯誤處理功能。

這並非可有可無的功能。這關乎是在編輯器中發現錯誤和在凌晨兩點在生產環境中發現錯誤之間的差異。

中間件的出現進一步拉大了差距。 TanStack Start 中間件既可在請求層也可在伺服器函數層工作，用戶端和伺服器端均可使用。您可以將多個中間件串聯起來，每一層都會將類型化的上下文傳遞給下一層。例如，驗證中間件會驗證會話並提供user物件；權限中間件會接收該類型化的user並檢查存取權限；日誌記錄中間件則會同時接收這兩個物件。每一層都有完整的類型推斷，無需any類型轉換，也不會出現執行時意外情況。

const authMiddleware = createMiddleware().server(async ({ next }) => {
  const user = await validateSession()
  if (!user) throw redirect({ to: '/login' })
  return next({ sendContext: { user } })
})

const getProtectedData = createServerFn({ method: 'GET' })
  .middleware([authMiddleware])
  .handler(async ({ context }) => {
    // context.user is fully typed here. No cast needed.
    return db.getData(context.user.id)
  })

在 Next.js 16 中， middleware.ts被重新命名為proxy.ts 。它執行在網路邊緣，先於你的應用程式程式碼。它無法存取你的資料庫，無法執行伺服器端邏輯，且其執行模型與路由處理程序截然不同。對於重定向和請求頭操作之外的任何操作，你需要使用伺服器操作或 API 路由，它們是具有不同思維模型的獨立概念。

那個揮之不去的SEO迷思

這部分內容最能節省大家的時間，因為開發者不假思索地選擇 Next.js 的首要原因就是 SEO。他們的假設是：Next.js 支援 SSR 和靜態內容生成，Google很喜歡它，而 TanStack Start 是個新來者，所以可能沒辦法與之競爭。對吧？

錯了。而且差得遠呢。

TanStack Start 預設啟用完整的伺服器端渲染 (SSR)。當 Googlebot 造訪您的頁面時，它會收到完整渲染的 HTML，所有內容都清晰可見。抓取過程中無需執行任何 JavaScript。這與 Next.js 的工作原理相同。 HTML 直接從伺服器完整載入。

但讓我來向您展示一下 TanStack Start 的 SEO 工具實際上是什麼樣子，因為沒有人談論過這一點：

export const Route = createFileRoute('/posts/$postId')({
  loader: async ({ params }) => {
    const post = await fetchPost(params.postId)
    return { post }
  },
  head: ({ loaderData }) => ({
    meta: [
      { title: loaderData.post.title },
      { name: 'description', content: loaderData.post.excerpt },
      { property: 'og:title', content: loaderData.post.title },
      { property: 'og:image', content: loaderData.post.coverImage },
      { name: 'twitter:card', content: 'summary_large_image' },
    ],
    scripts: [
      {
        type: 'application/ld+json',
        children: JSON.stringify({
          '@context': 'https://schema.org',
          '@type': 'Article',
          headline: loaderData.post.title,
          author: { '@type': 'Person', name: loaderData.post.author.name },
          datePublished: loaderData.post.publishedAt,
        }),
      },
    ],
  }),
  component: PostPage,
})

這包括元標籤、Open Graph、Twitter Cards 和 JSON-LD 結構化資料，所有這些都由類型化的載入head資料驅動，並在頁面到達瀏覽器之前在伺服器端渲染。 head 函數接收與元件相同的類型化loaderData ，因此您的 SEO 元資料始終與頁面內容保持同步。無需單獨獲取元標籤的資料。標題和頁面內容完全一致的情況不會發生。

TanStack Start 還具有靜態預先渲染和自動網站地圖產生功能：

// vite.config.ts
tanstackStart({
  prerender: {
    routes: ['/blog', '/blog/posts/*'],
    crawlLinks: true,  // discovers all linked pages automatically
  },
  sitemap: {
    enabled: true,
    host: 'https://yoursite.com',
  },
})

建置時產生靜態 HTML 頁面。自動抓取連結以查找所有路由。產生sitemap.xml 。並使用標準 HTTP 快取頭進行 ISR（增量靜態重生成），可與任何 CDN 相容，而不僅僅是 Vercel 的 CDN。

TanStack Start 甚至提供了針對 AI 搜尋時代的 LLMO（LLM 最佳化）文件。隨著來自 Perplexity、ChatGPT 搜尋和 Google AI Overviews 的流量增長，該文件展示瞭如何為 AI 爬蟲建置內容結構，包括對llms.txt的支持，llms.txt 是 AI 版的robots.txt的文件中目前還沒有這方面的內容。

那麼，Next.js 真正的 SEO 優勢體現在哪裡呢？主要體現在兩個方面。

首先， next/image 。自動響應式圖片、WebP/AVIF 格式轉換、延遲載入和內建 CDN 分發。圖片較多的網站的核心 Web 指標會顯著提升。 TanStack Start 沒有圖片元件。您需要使用 Cloudflare 圖片調整、imgproxy 或類似的第三方服務。雖然可行，但並非零配置。

其次，部分預渲染。 Next.js 16 可以立即提供一個靜態框架，同時將動態內容串流到 Suspense 邊界。靜態部分會在伺服器完成動態內容的運算之前到達瀏覽器。對於具有一定個人化功能（例如角落顯示使用者頭像、靜態文章下方顯示即時評論）的內容網站來說，這確實能帶來顯著的效能提升，而 TanStack Start 目前還無法與之匹敵。

但就實際的SEO基礎功能（伺服器端渲染的HTML、元標籤、結構化資料、網站地圖、靜態網站產生、ISR）而言，這兩個框架不相上下。如果有人告訴你TanStack Start對SEO不利，那他肯定從2024年後就沒關注過它了。

無人質疑的數字

我從四個來源獲取資訊：GitHub 問題及其復現倉庫、Inngest 工程部落格（一家已遷移的真實公司）、Vercel 自己的文件以及來自開放問題的堆快照。

開發伺服器記憶體。

Next.js 開發伺服器在中等規模的應用程式上初始佔用約 300MB 記憶體。隨著路由的切換，記憶體佔用會不斷攀升。 GitHub 問題 #78069 記錄了記憶體佔用成長至 9-10GB 的情況。問題 #54708 已獲得 141 個贊，自 2023 年 8 月以來一直處於開放狀態。 Next.js 16 中的 Turbopack 顯著提升了建置速度（提升 2-5 倍，而且是真實存在的），但開發過程中記憶體佔用成長的問題在 2026 年 1 月的問題中仍然有記錄。

TanStack 啟動開發伺服器時佔用大約 200MB 的空間，並且一直保持在這個大小。 Vite 在啟動時幾乎不做任何操作，它只在使用者請求檔案時才轉換。

如果你用的是筆記型電腦，這一點很重要。如果你的團隊在內羅畢或拉各斯，使用只有 8GB 內存的電腦，開發伺服器要同時執行 Chrome 和 Figma，這意味著需要頻繁地交換內存，這一點就更加重要了。

生產記憶。

問題變得嚴重起來。 GitHub 上的 issue #88603（提交於 2026 年 1 月）針對 Next.js 16.1.0 版本，記錄了記憶體洩漏導致 Docker 和 Kubernetes 中出現 OOM 崩潰的情況。記憶體會在數小時內線性增長，直到 pod 被終止並重新啟動。 2025 年 11 月的 issue #85914 僅使用output: standalone和單一fetch呼叫）就重現了這個問題。報告者測試了 Node 20、22 和 24 版本，所有版本都存在相同的問題。

目前 GitHub 上有 6 個關於 Next.js 在容器化環境中記憶體洩漏的開放討論，時間跨度從 2021 年到 2026 年 1 月。模式相同：記憶體線性成長，垃圾回收無法回收，Pod 重新啟動。

我還沒有找到 TanStack Start 的類似報告。這可能是因為在生產環境中使用它的人比較少。但它更精簡的執行環境（沒有 RSC 協定、飛行格式、自訂序列化層）意味著漏洞外洩的可能性更小。請結合具體情況來理解這一點。

提升速度。

Turbopack 的速度確實很快，而且建置速度比 Webpack 快 2-5 倍。這是 Next.js 16 的最大優勢之一，而資料也證實了這一點。檔案系統快取也非常出色，快取預熱後，重啟幾乎是瞬間完成。

TanStack Start 使用了 Vite，而 Vite 本身速度就很快。建置時間也相差無幾。到 2026 年，這兩個框架都不會成為您 CI 管線的瓶頸。

捆綁包大小。

Next.js 的基礎版本壓縮後約為 92KB。借助伺服器端元件，主要由靜態內容組成的頁面可以顯著減少 JavaScript 的載入量，因為元件程式碼保留在伺服器端。

TanStack 的初始基線大小約為 42KB。所有內容都在客戶端進行加載，因此會打包更多的 JavaScript，但總大小仍然較小，因為沒有 RSC 執行時開銷、飛行協議和序列化層。

對於以伺服器端元件為核心的內容網站，Next.js 打包的 JavaScript 程式碼較少。而對於大多數元件最終都會被設定為"use client"互動式應用，TanStack Start 打包的程式碼也更少。在進行優化之前，務必先了解你的應用程式。

真實的移民資料。

開發者工具公司 Inngest 在 2026 年初發布了他們的遷移案例。遷移前，基於 Next.js：本地頁面載入每個路由都需要 10-12 秒。遷移後，基於 TanStack Start：首次載入僅需 2-3 秒，後續路由幾乎瞬間完成。整個遷移過程耗時兩週，由一名工程師在 AI 輔助下完成。他們在 Slack 上最常提到的一句話是：“簡直難以置信，速度竟然這麼快！”

另一支團隊記錄了將生產應用程式從 Next.js 16 遷移後，建置時間減少了 60%，並且完全消除了水合錯誤。

兩個資料點，並非趨勢。但它們與架構預測的結果一致。

您需要了解的安全事件

2025年12月，CVE-2025-55182被分配到React伺服器元件協定。 CVSS評分：10.0（滿分10分），最高嚴重度。未經身份驗證的遠端程式碼執行漏洞，影響所有Next.js應用程式路由部署。

兩個月內共發現 6 個 CVE，全部與 RSC 的實作有關。

這個問題已經修復了。如果您使用的是 Next.js 16.1.6 版本，則無需擔心。但這暴露了這些框架之間架構上的差異，而這些差異會影響您的風險評估。

React 伺服器元件在用戶端和伺服器之間新增了一個協定層。此層包含序列化格式、傳輸機制和信任邊界。每個協定層都是攻擊面。這並非批評 Next.js 團隊的安全實踐，而是結構性問題：元件越多，潛在的風險就越大。

TanStack Start 使用純 HTTP 協定實現伺服器功能，採用標準的請求/回應機制。其攻擊面與任何 Express 或 Fastify 伺服器相同。無需自訂協定、飛行格式或新型序列化方式。

如果你身處受監管的行業，如果你有合規要求，或者如果你的威脅模型不僅僅涉及腳本小子，那麼這種差異就值得重視。

錢

Vercel Pro 的費用為每位使用者每月 20 美元，另加使用費。一個 5 人團隊在網站尚未獲得任何訪客之前，每月就要支付 100 美元。隨著流量的成長，費用也會攀升。規模較大的團隊每月費用高達 500 至 2000 美元甚至更高。

Next.js 在其他平台上也能正常運作，例如 AWS、Railway、Fly.io 和 VPS。但最流暢的使用者體驗、無需配置即可使用的功能以及零負擔的部署，都是針對 Vercel 平台優化的。 Vercel 的獲利模式正是如此。他們打造了一個優秀的框架和一個出色的託管平台，並將它們設計成最佳的協同工作環境。這是一種合法的商業模式，但請記住，這是交易的一部分。

TanStack Start 可部署到任何執行 Node 的平台。每月 24 美元的 Hetzner VPS 就能處理出乎意料的流量。免費套餐中的 Cloudflare CDN 足以滿足大多數應用程式的需求。生產環境部署每月不到 30 美元。

同等規模的團隊每月在 Vercel 上花費 500 美元以上，而自架的 TanStack Start 每月執行成本為 100-400 美元。一年下來，就是 5000-20000 美元。三年下來，隨著業務成長，總成本將達到 50000-200000 美元。

但自架代表您需要自行處理部署、監控、SSL 和事件處理。如果您只有兩名工程師，且缺乏 DevOps 經驗，Vercel 的高級版可以為您節省時間。如果您有基礎設施人員，那麼節省的成本將非常可觀。

Next.js 在這方面完勝，而且優勢明顯。

內容驅動型網站。部落格、行銷網站、電商產品目錄、文件，任何頁面主要由文字和圖片構成，互動性較弱的網站。正如我在 SEO 部分提到的，這兩個框架在基礎功能方面都表現出色。但伺服器元件賦予 Next.js 一項關鍵優勢：靜態頁面無需任何 JavaScript 程式碼即可載入。 "use cache"指令使快取機制更加明確清晰。部分預先渲染技術可以即時提供靜態頁面框架，同時即時載入動態內容。對於那些載入時間即使幾毫秒都會影響轉換率的內容來說，這就是 TanStack Start 目前無法比擬的真正優勢。

生態系。 TikTok 、Nike、Hulu、Target、《華盛頓郵報》。 Next.js 的運作規模是 TanStack Start 從未見過的。如果遇到問題，Stack Overflow 總是能找到答案。招募也更容易，因為每個 React 開發者都至少有一些 Next.js 經驗。各種整合庫應有盡有。多年累積的經驗，你都可以免費繼承。

圖片管道。 next next/image可以自動處理響應式尺寸調整、懶加載、格式轉換和 CDN 分發。 TanStack Start 沒有類似的功能。對於圖片密集型網站來說，僅憑這一點就足以證明 Next.js 的價值。

穩定性。 Next.js 16 是一個穩定版本。 TanStack Start 是一個候選版本。 API 已凍結，Tanner 承諾在 1.0 正式版發布前不會進行任何重大更改。但候選版本意味著更少的生產部署、更少的極端情況發現以及更少的開發痕跡。如果您需要向您的 CTO 說明“這是經過生產驗證的”，Next.js 就是最誠實的答案。

句號。

TanStack Start 勝出，而且優勢明顯。

互動式應用。儀錶板、管理面板、內部工具，任何使用者互動多於閱讀的應用。在這些應用中，幾乎每個元件都需要客戶端狀態，這意味著在 Next.js 中幾乎所有內容都需要"use client" ，因此伺服器元件無法發揮作用。 TanStack Start 讓您無需費力就能在所有應用場景中使用 React，而無需與為其他用例設計的架構對抗。

類型安全。這不是偏好，而是能力差距。經過驗證的類型化路由參數。使用 Zod schema 的類型化搜尋參數。從伺服器到元件的類型化載入器資料無需任何強制as轉換。跨層進行上下文推斷的類型化中間件鏈。在 Next.js 中，參數是非同步 Promise，而搜尋參數是非類型化的字串。對於大型應用程式，這可以避免許多類型的生產環境 bug。

在真實硬體上獲得開發體驗。如果你的開發伺服器佔用 6-10GB 內存，那麼你的應用程式就只能與 Chrome 和 Figma 並行執行，而無法單獨執行並等待。 TanStack Start 只佔用約 200MB 的空間，確保你的機器快速回應。對於以 8GB 或 16GB 記憶體為標準配置的團隊來說，這決定了你是高效工作還是焦頭爛額。

部署自由。 Node 、Deno、Bun、Cloudflare Workers、任何 VPS、任何容器平台，統統沒問題。沒有任何主機提供者會獲得特殊優待。框架本身並不關心運作環境。對於希望擁有自己基礎設施的團隊來說，這直接轉化為成本節約。

中介軟體.可組合、類型化，可在請求層和伺服器函數層執行，客戶端和伺服器端均可使用。身份驗證中間件提供類型化的用戶，權限中間件提供類型化的存取權限，進而存取資料中間件。每一層都完全推斷。沒有any 。在 Next.js 中， proxy.ts在邊緣執行，其執行模型與路由處理程序不同。對於複雜的後端邏輯，TanStack Start 的中間件是更強大的原語。

毫無懸念。