如果你在过去几年里一直在各种元框架（meta-frameworks）之间跳来跳去，那么 SvelteKit 2 会让你感到一种既释然又怀疑的奇妙混合感。释然，是因为它实际上是在简化复杂度，而不是增加复杂度。怀疑，是因为你总是在等着“意料之外的麻烦”降临。但它从未真正发生。配合 Svelte 5，这一技术栈是 2026 年交付全栈应用最高效的方式之一，而且数据也证明了其卓越的开发者体验。打包体积比 Svelte 4 生成的体积大约缩小了 35%。路由、服务端函数和身份验证模式都是一等公民，而不是需要你用胶带胡乱粘凑在一起的插件。

Runes 让响应式变得显式化

最大的思维转变来自于 Svelte 5 的 Runes。之前的 Svelte 版本使用 $: 标签和大量的编译器魔法来追踪依赖。它确实有效，但一旦出问题，你就像是在调试看不见的电线。Runes 用显式函数取代了那种魔法。你明确告诉编译器需要追踪什么，它就会照做。

以下是你需要了解的内容：

  • $state 处理响应式变量。将任何值包裹在 $state() 中，编译器就会知道要监听它。
  • $derived 从其他状态计算值。需要过滤列表或格式化总计？使用 $derived。与 $effect 的关键区别在于 $derived 用于值，而不是动作。
  • $effect 运行副作用。例如更新文档标题、手动 DOM 测量或需要清理的定时器。它在 DOM 提交后运行，类似于生命周期钩子，但与特定的响应式依赖项绑定。
  • $props 取代了旧的 export let 模式，用于在组件中接收数据。它更清晰，且与 TypeScript 的交互更好。

这种模型在实践中得到了回报。因为编译器只追踪你标记的内容，死代码就保持为死代码。你不再纠结为什么某个变量触发了更新，而是开始信任你自己的显式指令。

基于文件夹而非配置的路由

SvelteKit 使用文件系统进行路由。不需要维护单独的路由文件。将一个 +page.svelte 文件放入目录中，该目录就会变成一个活跃路由。

通过 +layout.svelte 为这些路由提供共享 UI 包装。将其放在根目录下，所有子路由都会继承它；将其放在树结构的更深层，则只有该部分会获得包装。

服务端逻辑位于 +page.server.ts 中。它在页面渲染前运行，因此可以在此处查询数据库、验证 Cookie 或拒绝未授权用户。类型会从你的 load 函数自动流向页面组件，这意味着你无需手动编写接口即可实现数据类型化。

原始 API 端点放在 +server.ts 文件中。它们导出标准的 HTTP 处理程序——GET、POST、PUT、DELETE——因此在页面旁构建 REST 后端感觉非常自然。

一个被低估的功能：路由分组。通过在文件夹名称两端加上括号，例如 (auth)，你可以创建一个共享布局，而不会在 URL 中增加路径段。这对于登录和注册页面非常完美，它们需要相同的精简界面，但路径应为 /login 和 /signup，而不是 /auth/login。

数据、安全与渐进式增强

现代框架喜欢谈论全栈，但许多框架会让你猜测该把身份验证检查或表单逻辑放在哪里。SvelteKit 为你提供了清晰的钩子。

使用 +page.server.ts 进行数据获取。那里的 load 函数仅在服务端运行，因此你的数据库凭据永远不会泄露到浏览器。SvelteKit 根据你的 load 返回值生成类型，从而保证前端数据的准确性。

使用 hooks.server.ts 来管控整个应用程序。它在每次请求时运行，是验证会话、检查 JWT 过期或将用户上下文附加到传入事件的最佳位置。

对于数据变更（mutations），请使用表单操作（form actions）。与其连接一个单独的 API 端点并处理 JSON，不如在 +page.server.ts 中定义一个 action。这里的妙处在于渐进式增强。如果 JavaScript 加载失败——或者用户禁用了 JavaScript——表单仍然会提交到服务端 action，页面会随结果重新渲染。如果存在 JavaScript，SvelteKit 会在无需完整刷新的情况下增强体验。你可以用同一套代码获得韧性和精致感。

需要记住的一条规则：在 $derived 中进行计算，而不是在 $effect 中。使用 $effect 来计算值可能会触发难以追踪的更新循环。将 $effect 留给真正的副作用，让 $derived 负责你的计算状态。

SvelteKit 对比 Next.js

这两个框架都可以用于交付生产级应用，但它们之间确实存在权衡。

包体积方面 SvelteKit 更具优势。由于 Svelte 将组件编译为原生 JavaScript 并完全跳过了 Virtual DOM，因此运行时占用保持在很小的范围内。Next.js 则需要携带 React 的协调引擎。

响应式机制也不同。SvelteKit 在编译时解析 runes。浏览器接收到的是纯粹的更新。Next.js 则依赖 React 的运行时 hooks 和协调机制，这意味着客户端需要承担更多的工作。

SvelteKit 的上手门槛更低。其心智模型更简单。你不需要为了避免重新渲染而费力处理 useEffect 的依赖数组或记忆化难题。TypeScript 的集成也值得一提。虽然这两个框架