# SvelteKit 文档开篇说自己像 Next，路由和 load 怎么分？

**URL:** <https://www.shiqidu.com/t/topic/2016>\
**Category:** 开发调优\
**Tags:** 问与答, JavaScript, 前端开发, Node.js, 开源软件\
**Created:** [2026 年11 月 10 日 11:15 UTC](https://www.shiqidu.com/t/topic/2016 "2026-11-10T11:15:07Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

作者： ![shiqidu\_editor](https://www.shiqidu.com/user_avatar/www.shiqidu.com/shiqidu_editor/32/528_2.png) [@shiqidu\_editor](https://www.shiqidu.com/u/shiqidu_editor)\
发布日期： [2026 年11 月 10 日 11:15 UTC](https://www.shiqidu.com/t/topic/2016/1 "2026-11-10T11:15:08Z")

</div>

团队里有人想试 Svelte 全栈栈，书签一打开却先撞上「Svelte 组件」和「SvelteKit 应用」两套说法。页面组件能画出来，URL、SSR、首屏数据又各管各的，心智容易糊成一团。[SvelteKit Introduction](https://svelte.dev/docs/kit/introduction) 把边界写得很清楚：Svelte 负责界面组件。要做整站，还得靠 Kit 补上路由、按需加载、渲染模式这类常见工程问题。下面只抠官方开篇和紧邻的路由 / 数据加载心智，不写踩一捧一的框架长评。

## Kit 把自己摆在哪一格

Introduction 的定义是：用 Svelte **快速开发稳健、高性能 Web 应用** 的框架。对照其他生态，文档直接说：从 React 过来，Kit 类似 Next。从 Vue 过来，类似 Nuxt。这句话只作定位，不是选型结论。

同一页还拆开了两层：

- Svelte：写导航栏、评论区、表单这类用户看得见的组件。编译器把组件转成渲染 HTML 的 JS，以及样式 CSS。
- SvelteKit：在组件之上补「整站」能力——点链接时更新 UI 的路由器、只加载必要代码的构建优化、离线支持、导航前预加载、可按区块配置 SSR / 客户端渲染 / 预渲染、图片优化，以及基于 Vite 的 HMR。

换句话说，只靠 Svelte 也能拼出页面，但官方认为现代应用还要处理的那堆「无聊但必要」的事，交给 Kit。开发体验也写明：改代码能立刻反映到浏览器，靠的是 Vite 加 Svelte 插件做热更新。

## 路由：目录就是路径，文件带 `+`

[Routing](https://svelte.dev/docs/kit/routing) 把主线写成 **基于文件系统的路由器** ：`src/routes` 是根。`src/routes/about` 对应 `/about`。`src/routes/blog/[slug]` 带动态段。路由目录里用带 `+` 前缀的文件约定职责，例如：

- `+page.svelte`：页面本身。默认首屏 SSR，后续导航走客户端渲染。
- `+page.js` / `+page.server.js`：给页面准备数据的 `load`（见下一节）。
- `+layout.svelte`：跨页共用的壳（导航、页脚），可嵌套。子目录布局继承上层。
- `+error.svelte`：`load` 出错时就近找错误边界。
- `+server.js`：同一路径上的 API / 端点，导出 `GET`、`POST` 等。

文档还强调用普通 `<a>` 做站内跳转，而不是框架专用的 Link 组件。页面通过 `data`（以及较新版本里的 `params`）接收上游准备好的数据。从 A 页切到 B 页时，两边共用的布局组件会被保留，不必整树拆掉重建。这点和「每个 URL 整页重刷」不是同一套手感。

## 数据加载：先 `load`，再渲染组件

[Loading data](https://svelte.dev/docs/kit/load) 写得很干脆：在 `+page.svelte`（以及布局）渲染之前，通常先跑 `load`，返回值进 `data`。两条常见分岔：

- `+page.js` 里的 **universal** `load`：默认 SSR 时在服务端跑，之后在浏览器里也会跑（可用页面选项改）。适合拉公开 API、不需要私钥的场景。
- `+page.server.js` 里的 **server** `load`：只在服务端。碰数据库、私有环境变量时用它。返回值要能被序列化，才能送到浏览器。

布局也可以有自己的 `load`，子页面能读到父级数据。密钥、连接串这类东西别塞进会下发到客户端的 universal 路径——该落 server 文件就落 server 文件。同一路由上若既有 server `load` 又有 universal `load`，服务端那份会先跑，结果再作为 universal 侧的 `data` 入参，而不是两份各写各的互相看不见。

## 落地时容易混的两处

第一，别把「会写 `.svelte` 组件」当成「已经会用 Kit」。Introduction 明确：组件解决 UI。应用还要路由与数据约定。第二，别把 `+page.js` 和 `+page.server.js` 当成同义词——一个可能两边跑，一个钉死在服务端，选错会把不该出门的凭据带进打包结果。

官方还推荐新手先走交互式教程。卡壳可以去 Discord。选型对比留给你们自己的约束清单，这里只对齐文档心智。

你们仓库里若已经有一套约定俗成的「路由文件 + 数据钩子」命名，和 Kit 的 `+` 约定对得上吗？