SvelteKit 3 发布：配置并入 vite.config.ts，$lib 改为 #lib

Svelte 团队 10 月 1 日发布 SvelteKit 3.0，官方基调是「同一个框架，多一分打磨、少一分杂物」——不是重写，是一次把欠账清掉的结构整理。

事实部分

• 配置合并：svelte.config.js 废弃，配置迁入 vite.config.ts——框架配置与构建配置单点化。
• 别名变更：$lib 改为 #lib，走 Node 标准 subpath imports。
• 其他改进：环境变量处理、service worker 样板、错误处理均有整理。
• 迁移：npx sv migrate sveltekit-3 自动处理。
• 下一优先级：类型安全的 Remote functions（客户端-服务端 RPC），但依赖实验性 Async Svelte，本次未转正。
• 日程：11 月 19-20 日 Svelte Summit（卢布尔雅那）恰逢 Svelte 十周年。

与 Vite 合流的信号

框架配置并入 vite.config.ts 意味着 SvelteKit 正式以 Vite 为运行时骨架、把「框架特殊配置」降到最少。这与 SolidStart 2（同样转向 Vite 8）方向一致——元框架的竞争焦点从「自带构建」转向「谁把 Vite 用得最干净」。

升级建议

破坏性变更集中在配置与别名两处，机械性强：跑官方迁移脚本后重点检查 CI 里的 svelte.config.js 引用与动态 import $lib 的路径。Svelte 5 的 runes 未受影响，组件层不用动。

本周的另一场 3.0

同一周里 WSL 3.0 也完成了大版本：两个 3.0 都是「结构整理优先于新功能」的发布——基础设施与框架层在 AI 变革的喧嚣里悄悄还债。

编辑判断

「少一分杂物」的发布哲学在 AI 生成代码泛滥的当下反而稀缺：SvelteKit 3 没有新范式，只有整理。对一个十岁的框架，这比追赶每个热点更难。Remote functions 若在 Async Svelte 转正后落地，SvelteKit 将拥有同类框架里最简的全栈类型安全方案——那才是 4.0 的真正卖点。

迁移面的实际工作量

团队按「一天」而不是「一个冲刺」预算：配置合并是机械操作，$lib 到 #lib 是全局替换（动态 import 最后处理），环境变量与 service worker 整理是增量式的。真正的审计点是读 svelte.config.js 的周边工具——ESLint 配置、部署 adapter、编辑器插件都要指向新位置。Svelte 5 runes 代码零改动。

意义大于 changelog

一个框架把大版本花在「做减法」上，等于宣告自己的风险位在哪：SvelteKit 的差异化是每 KB 的开发体验，而杂物——配置蔓延、样板、特例——正是侵蚀它的税。Remote functions 仍是路线图主角；如果它随 Async Svelte 转正，客户端-服务端将有不需要独立 API 层的类型安全方案——这是对 Next.js 与 SolidStart 在 islands+RPC 时代最有力的回应。 减法本身就是战略。

生态侧的读法

SvelteKit 的 adapter 面（Vercel、Netlify、Cloudflare、Deno）现在都跟着 vite.config.ts 走，主流 adapter 当天完成兼容——Vite 插件契约的标准化程度可见一斑。对 2026 年末选元框架的团队，真正的差异点在部署目标与 RPC 人体工学，不在构建工具；SvelteKit 3 主动拆掉构建工具这个差异点，是刻意的收敛动作。 这次整理还顺带打通了 AI 工具链的故事：单一 vite.config.ts 让编辑器与智能体生成的配置更少出错。

值得一提：发布说明把迁移生成器的功劳记给了 AI 辅助工具——框架团队和用户用的是同一类加速器。 配置进 Vite 还意味着脚手架工具少了一个会过期的文件。 十一月的 Svelte Summit 议程将展示路线图与 Async Svelte 碰撞后还剩多少。 导出虚拟 $lib 模块的库需要做同样的 #lib 处理。 对维护大量客户站点的代理商，一条命令的迁移才是这版真正的功能。

最后的提醒：dev 与 build 都走同一份 vite 配置后，环境相关的条件配置要在两个入口各验一遍。

迁移脚本同时处理 dev 与 build 两处入口的环境条件配置，monorepo 场景需先按应用拆分。