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

SvelteKit 的設計前後一致：預設 SSR + client hydration，load 函式能在 server 和 browser 執行，form actions 優先於 REST，有 JS 時再透過 progressive enhancement 補上互動。server 側負責資料抓取、權限檢查與 redirect，client 側接手互動；+page.server.ts 放 server-only 邏輯，+page.ts 放兩側都能跑的部分，只有真的要提供 API 才開 endpoint。這套分工的 DX 很完整，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 翻新計劃，新漆未乾。