SvelteKit 預設 SSR 的世界觀，以及它哪裡會卡你

SvelteKit 的世界觀其實很連貫：預設 SSR + client hydration，load 函式在 server 和 browser 都能跑，form actions 優先於 REST，progressively enhance 到有 JS 再加行為。這套設計哲學很連貫，server 側做資料抓取、權限檢查、redirect，client 側接手互動。+page.server.ts 處理 server-only 邏輯，+page.ts 處理兩側都能跑的邏輯，endpoint 是真的要做 API 時才用。說實話，這是我看過 DX 最完整的 meta-framework 之一，form actions 那層設計得很直接。

問題是，預設替你包好那麼多，環境一不對就報應來了。我踩過的最慘案例：後台跑在網路磁碟上（某家公司的 NAS mount），SvelteKit 啟動時 Vite 要掃模組、轉換依賴，在本地磁碟可能三秒，在 NAS 上直接掛超過 60 秒，偶爾根本沒辦法等。這不是 SvelteKit 的 bug，Vite 的 dev server 原本就吃 I/O，但你掛在慢儲存上就是這樣。production build 也一樣，每次 vite build 就要等一陣子。

最後決定把那個後台砍掉重練，改純 Svelte SPA（不是 SvelteKit），自己寫了約 80 行的 hash router，零外部依賴，state 全在 client，API 打後端 endpoint。整件事花了半天，之後再也沒有 Vite 轉換塞住的問題。這個選擇沒辦法普遍化，但在那個環境下就是最務實的路。

結論不是 SvelteKit 壞掉了，是你要清楚它預設幫你做了什麼：SSR 的模組系統、Vite 的 dev server、hydration 的開銷，這些都有成本，而且成本在特定環境下會被放大到難以接受。知道這件事，你才能在對的時機選擇退出那個預設，而不是埋頭調 Vite cache 設定調到天亮。

重點整理

• SvelteKit 的 SSR + form actions 設計很有道理，server 側先做完邏輯、client 側接手互動，是合理的分工。
• Vite 的模組轉換吃 I/O，跑在網路磁碟或慢儲存上可以慢到無法使用。
• 後台、工具頁、低互動頁面用純 Svelte SPA + 簡單 hash router 有時是更務實的選擇。
• 框架的預設是為了主流環境最佳化，不是承諾在所有環境都好用。
• 知道自己退出了什麼預設，比不加思索用框架或不加思索棄掉框架都重要。

觀點 Sheng，內文 Claude 協助 · 列入 20260613 blog 翻新計劃，新漆未乾。