從框架定位談起
SvelteKit 是 Svelte 的官方應用框架，由 Svelte 團隊維護，該團隊目前屬於 Vercel。它建構在 Vite 之上，負責路由、伺服器端渲染、資料載入與部署轉接器，讓開發者可以用以編譯器為核心的 Svelte UI 框架來打造全端網頁應用，而不是依賴虛擬 DOM。自 2022 年底推出 1.0 版以來，SvelteKit 已成為開發 Svelte 應用的預設選擇，並在定位上與 Next.js、Remix 等 React 框架競爭，主打 Svelte 較小的執行期負擔與反應式語法。InfoQ 報導指出，Svelte 團隊已把 SvelteKit 3 推進到釋出候選版階段，並將這次更新描述為清理舊程式碼、為框架後續演進鋪路的機會，而不是一次功能密集的大改版。若測試順利，接下來會推出不再有破壞性變更的穩定版。
設定集中到 Vite 的原因與影響
這次最受矚目的變動，是設定檔位置的改變。SvelteKit 2 的 svelte.config.js 不再存在，設定改放到 vite.config.ts，讓 Vite 外掛能同步讀取設定，而不必等待一個非同步解析步驟；在舊做法中，該步驟必須等完整 Vite 設定解析完成後才能開始。參考文件提到，透過 Vite 進行設定早在 2.62 版就已出現，因此這次釋出候選版更像是把已經進行中的過渡正式定案。對開發者而言，這代表設定來源更集中，也更能貼近 Vite 生態系的載入順序；但同時，既有專案若仍依賴舊的設定方式，就需要在升級時一併調整。
$lib 退場與原生子路徑匯入
討論度最高的改變，是 $lib 別名退場，改由井號開頭的 lib 別名取代。新的做法依賴 Node 原生子路徑匯入，並在 package.json 中宣告，而不是使用 SvelteKit 專屬路徑；舊路徑需要 Vite 與 TypeScript 互相協調，新做法則回到 Node 既有的模組解析機制。開發者現在也必須寫出副檔名，原本的 $lib/foo 要改成井號開頭的 lib/foo.js。官方遷移指南建議既有應用使用 CLI 進行遷移，透過 npx sv@next 執行 sveltekit 3 的遷移任務，並帶上 tasks all 與 confirm 參數。在 Reddit 上，有開發者表示不喜歡這項改動，認為它讓 lib 別名與 $app 等其他寫法變得不一致，並希望框架不要強制只能使用井號開頭的 lib，而是允許開發者自訂別名。不過也有回覆者一開始同意這種質疑，隨後改口認為這是很好的改變，因為別名定義回到原生 package.json 之後，就能用在可能不需要 SvelteKit 也能執行的 lib/server 程式碼中。維護者 Rich Harris 在原本的 GitHub 議題中坦言這是取捨：他很希望所有人都採用 nodenext，但也擔心使用者會因為必須加上副檔名而反彈，並表示反對者永遠可以建立自己的別名。
型別、環境變數與錯誤處理的調整
在型別與環境設定方面，tsconfig.json 現在改為延伸 $app/tsconfig，而不是先前由工具產生的隱藏設定檔。Service Worker 則從 $app/env、$app/paths 以及新的 $app/manifest 模組取得資訊。明確的環境變數也從實驗性階段畢業，並可選擇搭配 Standard Schema 進行驗證。錯誤處理同樣有進展：SvelteKit 3 要求使用 Svelte 5，+error.svelte 元件會在載入失敗與渲染失敗時都能呈現，所有錯誤都會流經 handleError，堆疊追蹤也會取得 sourcemap。淺層路由則從 pushState 改為使用帶有 shallow: true 選項的 goto。這些調整多半不是全新概念，而是把既有行為收斂到更一致、更容易追蹤的路徑上。
底層建置與仍在前沿的功能
底層方面，SvelteKit 3 要求 Vite 8 及其 Rolldown 打包器，以換取更快的建置速度。Rolldown 是以 Rust 撰寫的打包工具，目標是承接 Rollup 相容性並改善效能；不過團隊拒絕採用 FetchableDevEnvironment，理由是那會迫使框架吸收過多複雜度。仍處於實驗旗標之後的則是 remote functions，這是一種型別安全的用戶端與伺服器之間 RPC 做法，概念上呼應 React Server Actions 與 Next.js 伺服器函式。團隊表示，相較之下會讓現有的 load 函式與 actions 看起來有點笨重。
實務意義與限制
對既有 SvelteKit 專案來說，這次釋出候選版傳達的訊號很清楚：框架正把自訂機制往網頁平台與 Vite 的標準做法靠攏，減少 SvelteKit 必須自行維護的別名與設定路徑。這樣做的好處是設定來源更單一，工具鏈之間的協調成本較低，模組解析也更接近 Node 生態系的預期。代價則是升級時必須面對副檔名、別名與設定檔位置的變動，對大型專案或高度依賴舊別名的程式碼庫而言，遷移工作量不能忽視。此外，遠端函式等功能還在實驗階段，團隊也明確拒絕部分可能增加複雜度的提案，代表 SvelteKit 3 的穩定版並不會把所有新想法一次收進來。由於目前仍是釋出候選版，正式穩定版是否還會出現破壞性變更，取決於測試結果；在正式版推出前，開發者應以遷移指南與實際測試為準。本文根據 InfoQ 於 2026 年 9 月 30 日由 Daniel Curtis 撰寫的報導整理。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。