本頁內容
對獨立創辦人來說，把時間花在框架遷移上，感覺有些奇特。你可能做完大量工作，客戶眼前卻還是同一顆按鈕。
這仍可能值得，但理由得比「想換最新技術」更充分。
Bisonflow 2.0 的程式碼從 Next.js 移到 TanStack Start。這是一個讓人切換篩選、查看任務、編輯文件、比較時間軸、往返不同專案的工作空間。重建這些體驗時，我希望路由與資料行為更容易追蹤。
這篇說明這個選擇為什麼適合 Bisonflow。我沒有做受控的框架效能比較，也不會把偏好包裝成測量結果。
這本來就是高度互動的應用程式
專案工作空間裡，大部分重要行為發生在首次載入之後。篩選改了、詳細面板開了、某人改了任務，周圍檢視就該跟著一致。網址也應保留足夠狀態，讓重新整理或分享連結不會變成另一種體驗。
TanStack Router 提供明確路由樹、經驗證的搜尋參數、loader 與路由層級的頁首設定；TanStack Start 補上周圍的伺服器端能力。Convex 仍是後端，不會因為換框架，就多出第二份專案資料要管理。
我喜歡能在程式碼裡追蹤這些責任。這是針對這個應用程式的維護選擇。Next.js 也能支援互動產品；若為同樣理由搬一個小型內容網站，說服力就弱得多。
外界案例是有用的參考。TanStack 展示頁將 T3 Chat 列為 Start 應用程式，Next.js 遷移指南則說明路由、伺服器呼叫、metadata 與快取需要分別處理。其他產品的選擇值得研究，但不是我的遷移必然成功的證據。
轉換路由只是看得見的部分
改檔名令人滿足，因為進度容易數。真正困難的是路由周圍的存取控制、快取與伺服器行為。
直接請求私人頁面，必須和從 app 點進去一樣受保護。伺服器函式要驗證自己的呼叫者。快取得在正確時間停止沿用，包括帳號或工作空間切換時。
Bisonflow 裡，Clerk 管身分，Convex 管持久化資料，客戶端查詢快取則必須跟著身分走。公開頁面不啟動登入資料 provider，也不載入工作空間鍵盤操作層。讀者應該能打開文章，而不必啟動私人應用程式。
遷移也把框架專屬 request handler 換成 Start 伺服器路由與函式。包含發布截圖不會出現的部分：回應狀態、重新導向、私人快取標頭，以及最初 HTML 就具備的 metadata。
保留資料，就得讓舊假設仍可追蹤
重寫 UI 時，很容易順便想清理資料模型。新產品的確需要某些新增欄位，但換框架不是丟棄舊紀錄的理由。
遷移保留既有識別碼、檔案參照與計費紀錄。歷史文件快照仍在，新版以已儲存的文件作為內容依據，並透過暫時鎖定避免多人同時編輯。相容變更與範圍受限的遷移工作，讓轉換過程能被審查。
這些選擇很難成為公告的主角，卻比開發伺服器是否更舒服重要得多。
金錢也一樣。新框架、新視覺與規劃中的新方案是不同變更。前兩項不代表可以替任何人改訂閱價格。
SEO 也需要自己的遷移
Hydration 後才出現標題，不代表搜尋工作完成了。文章標題、canonical URL、分享圖片、404 回應與 sitemap，都需要明確負責的程式。
Start 能伺服器端渲染公開頁面，也能產生各路由的 metadata；但舊檔案還留在 repo，不會自動重建 Next.js 的慣例。圖片要準備合適尺寸，字型要安排載入方式，重新導向要當成真正請求檢查，不能只測客戶端導覽。
這提醒我：框架預設行為可能早已成為沒有寫下來的產品需求。移除框架後，需求仍是你的責任。
什麼情況代表這次遷移是錯的？
如果它讓日常改動更難理解、干擾既有工作存取，或延後有用的改善卻沒有降低維護成本，那我就是花錢追新鮮。
保留它的理由比較務實：路由、伺服器邊界與工作空間狀態，現在更符合我開發 Bisonflow 的方式。使用者應該在介面改版感受好處，框架本身則最好消失在背後。
是否適合正式上線，要靠應用程式的預期行為與部署結果的測試，不能靠一篇遷移文章來證明。
