Tanner Linsley 宣告 Start 正式生產就緒：型別安全路由、明確的伺服器函式、Vite／Nitro 部署自由，還把 Skills 塞進 npm 套件給 AI 代理。給想避開「全家桶框架」的 React 團隊一本實戰筆記。
做 React 專案的人都遇過這種尷尬：客戶問「你們用哪個框架？」工程師猶豫三秒，然後小聲說「我們用 TanStack Start……不過它還在 RC。」對方眼神瞬間變成「所以這算穩嗎？」
2026 年 10 月 13 日，TanStack 創辦人 Tanner Linsley 在官方部落格寫下〈TanStack Start 1.0 is Stable〉。重點只有一句：Start 正式穩定，可以當成生產就緒的選擇。 文章共同署名還有 Manuel Schiller、Florian Pellet、Christopher Horobin。同一天，Netlify Changelog 也宣布 Start 1.0 應用可部署到 Netlify，SSR、server routes、server functions 與 middleware 跑在 Netlify Functions 上，而且新的 Agent Runners 專案預設就用 Start 1.0。
對工作室來說，這不是「又多一個玩具」，而是：如果你一直想要 SPA 熟悉感、又想要 SSR／串流／伺服器函式，卻不想被單一框架的意識形態綁死，現在終於有一個「敢寫進合約」的選項。
它從路由器長大，不是先發明一個宇宙再塞路由
Linsley 回顧得很誠實：Start 不是從「我們要做下一個 Next.js」開始的。他想做的是自己想用的路由器——路徑存在與否、參數、search params、loader 回傳什麼、context 有什麼，全部透過 route tree 讓編輯器知道。改一處，型別錯誤立刻指出其他要改的地方。
當年（他寫 Router、甚至只是在研究時）很多人覺得這種型別深度「不可能」或「不值得」。他自己也說過，幾年前還覺得 TypeScript 多此一舉。是 React Query 團隊把 TS 當設計工具的經驗，改變了他。於是 Router 變成一場押注：把型別當成 API 的一部分來設計。
到了 2023 年 12 月左右，repo 裡已經有後來變成 Start 的伺服器工具雛形；2024 年 5 月，他把 react-router-server 套件改名成 start。框架命名儀式，官方說法是「配上一個滑稽 emoji」——聽起來不太正式，但路線很清楚：先有嚴格的路由與資料契約，再長出全端能力。
為什麼需要「另一個選項」？
文章把背景講得很直：當時 React 生態對「應用程式該長什麼樣子」的想像愈來愈窄。Next.js 大力押注 React Server Components；React Router／Remix 也在走自己的路徑。想法各自有趣，但 Linsley 不舒服的是——對話好像在逼所有人接受同一套答案。
他想保留過去十年熟悉的東西：狀態管理、客戶端導覽、資料快取，這些讓 SPA 生產力很高的零件；同時也要 SSR、串流、server functions——需要時把工作放伺服器，卻不必為此重學整個應用結構。
用他的話說：元件還是元件，路由還是路由；需要伺服器時，有非常直接、明確的用法。底層很複雜，但你不必在腦裡再維護「第二份應用說明書」。
實務上，Start 的路由可以：在伺服器渲染、在伺服器載入資料但不渲染元件、或在客戶端渲染。你可以用型別安全的 server function，從 loader 或事件處理器呼叫，並在客戶端與伺服器兩側組合 middleware，context 的型別一路帶過去。這對品牌電商、會員中心、後台這類「互動很多、又要 SEO／首屏」的台灣專案特別友善——不必一開始就全盤 RSC 化。
明確 API 長什麼樣子：createIsomorphicFn
官方舉了一個很小、但很能說明哲學的例子：取得目前 origin 來組絕對 URL。伺服器上從 incoming request 拿，瀏覽器上從 window.location 拿——兩個實作可以寫在一起：
import { createIsomorphicFn } from '@tanstack/react-start'
import { getRequest } from '@tanstack/react-start/server'
const getOrigin = createIsomorphicFn()
.server(() => new URL(getRequest().url).origin)
.client(() => window.location.origin)
const absoluteUrl = new URL('/about', getOrigin()).href
呼叫方式相同，實作依執行環境不同；Start 會把另一邊的實作從對應 bundle 拿掉。在瀏覽器呼叫不會因此打回伺服器。真的要打伺服器，才用 createServerFn。這種「看得到工作跑在哪」的控制感，正是很多團隊從黑盒子框架逃出來後最想要的東西。
效能、RSC，以及「可以拿掉」的自由
Linsley 特別點名 Manuel 與 Flo 的 SSR 效能工作：他們持續 profiling，拿掉伺服器不需要做的事，基準測試大約達到 5.5 倍吞吐量。Christopher 則撐起大量型別安全的效能工程，讓「超嚴格的型別」在真實編輯器裡跟得上。
關於 React Server Components，文章同樣坦白：有一段時間，支援 RSC 像是「想被當認真 React 框架就得勾的核取方塊」。團隊投入大量時間，Manuel 尤其用力研究如何在不讓 RSC 接管整個應用模型的前提下整合。他們甚至在 tanstack.com 上試過 RSC，後來因為 Markdown／語法高亮等成本與可讀性問題，決定拿掉——而且拿掉不需要重寫整個應用。需要時還可以再加回來。這種「可選、可進可出」的自由，才是 Start 想賣的東西，而不是功能對照表上多一個勾。
部署方面，他們聽了 Ryan Carniato 的建議，走 Vite＋Nitro，避免永遠維護一堆 deployment adapters。夥伴名單很華麗：Netlify（還把 Start 當 AI app builder 預設框架）、Render、Railway、Cloudflare Workers、Vercel，以及 Clerk、WorkOS、Sentry、Prisma 等整合。對客戶簡報時，「穩定版＋多平台可部署」這兩句話，比「我們跟最新潮流」有用多了。
AI 代理來了：型別原來也是給機器看的護欄
大約 2025 年 11 月起，AI 明顯改變了 Start 的開發節奏；到 2026 年初幾乎無處不在。PR 與 issue 暴增，其中不少是沒人讀過就丟上來的產生內容——維護者很頭痛。安全面也變了：有人用 AI 找漏洞，官方也和夥伴一起用 AI 主動找修。
有趣的轉折是：當年為了「人」做的型別安全與明確 API，現在對 agent 一樣有用。代理可以改掉路由參數或 server function 輸入，但接著需要工具告訴它哪些地方不再一致。Start／Router 不必為了 agent 重設計；嚴格契約剛好變成護欄。團隊還把 TanStack Intent 與 Skills 推進 npm 套件，讓代理拿到「怎麼用才對」的指引，而不是只靠訓練資料的記憶。
對工作室日常這意味著：新專案可以大膽跟代理說「用 TanStack Start」，遷移也可以讓代理搭配文件與測試一起做——但對不對仍然要人判斷；型別只保證改動還能對得起來。
給品牌與產品團隊的實作清單
- 先盤點互動密度：高度客戶端互動（篩選、儀表板、結帳多步驟）且又要 SSR／SEO 的站，Start 的「熟悉 SPA＋明確伺服器」很對味；內容為主、幾乎靜態的行銷頁，未必需要換棧。
- 用正式版重新寫進技術選型：RC 時期有些客戶不敢簽；1.0 之後可以明確寫「TanStack Start 1.0＋Vite」。
- 部署選平台，不要選宗教：Netlify 提供
@netlify/vite-plugin-tanstack-start，可在本機模擬 Functions、Blobs、Cache、Image CDN、AI Gateway；Cloudflare／Vercel／Render／Railway 也都有路徑。選你維運最熟的那一個。 - 把 Skills／文件當 onboarding：讓團隊與 coding agent 都讀官方文件與套件內 Skills，減少「靠印象寫成另一個框架」。
- RSC 當選配，不當信仰：需要把邏輯留在伺服器再考慮；不要為了簡報上的勾選而先綁死應用模型。
你可能會問
Q：已經用 Next.js 了，值得遷移嗎？
A：穩定執行且團隊熟練，不必為了新聞遷移。若你長期被「框架決定架構」卡住，或新產品想要更明確的伺服器邊界，可以用新專案或子應用試 Start，而不是大爆炸重寫。
Q：和 React Router／Remix 路線差在哪？
A：Start 建立在 TanStack Router 的型別優先模型上，強調 isomorphic／server function 的明確 API 與多托管自由。選擇時比的是團隊對「契約與控制感」的偏好，不是誰比較紅。
Q：AI 產生的 PR 會不會把 Start 專案弄亂？
A：官方自己也在扛這個問題。實務上：CI 要綠、型別要嚴、Skills 要新、人要審。1.0 讓契約更穩，不代表人可以放假。
結語
Start 1.0 真正宣告的，不是「我們功能比較多」，而是：你可以選它、學會它、上線，然後繼續蓋，不必擔心整套應用模型哪天被翻桌。 對台灣的品牌官網、電商前台與內部工具來說，這句話的價值往往大過任何一個新 API。
若你的下一個 React 專案需要 SSR、又想保住客戶端的生產力，現在可以把「TanStack Start 1.0」從備忘錄搬到正式架構圖上了——然後請代理幫忙開專案，人負責決定什麼該上伺服器、什麼該留在瀏覽器。
來源： TanStack Start 1.0 is Stable（Tanner Linsley，2026/10/13）；延伸：TanStack Start 1.0 deploys on Netlify（Netlify Changelog，2026/10/13）。