团队里有人想试 Svelte 全栈栈，书签一打开却先撞上「Svelte 组件」和「SvelteKit 应用」两套说法。页面组件能画出来，URL、SSR、首屏数据又各管各的，心智容易糊成一团。SvelteKit 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 把主线写成基于文件系统的路由器：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 写得很干脆：在 +page.svelte（以及布局）渲染之前，通常先跑 load，返回值进 data。两条常见分岔：
+page.js里的 universalload：默认 SSR 时在服务端跑，之后在浏览器里也会跑（可用页面选项改）。适合拉公开 API、不需要私钥的场景。+page.server.js里的 serverload：只在服务端。碰数据库、私有环境变量时用它。返回值要能被序列化，才能送到浏览器。
布局也可以有自己的 load，子页面能读到父级数据。密钥、连接串这类东西别塞进会下发到客户端的 universal 路径——该落 server 文件就落 server 文件。同一路由上若既有 server load 又有 universal load，服务端那份会先跑，结果再作为 universal 侧的 data 入参，而不是两份各写各的互相看不见。
落地时容易混的两处
第一，别把「会写 .svelte 组件」当成「已经会用 Kit」。Introduction 明确：组件解决 UI。应用还要路由与数据约定。第二，别把 +page.js 和 +page.server.js 当成同义词——一个可能两边跑，一个钉死在服务端，选错会把不该出门的凭据带进打包结果。
官方还推荐新手先走交互式教程。卡壳可以去 Discord。选型对比留给你们自己的约束清单，这里只对齐文档心智。
你们仓库里若已经有一套约定俗成的「路由文件 + 数据钩子」命名，和 Kit 的 + 约定对得上吗？