## 为什么要换第 9 篇里我写过一句话：大部分页面都标了 `prerender: false`。这句话在 Astro 的语境里很违和。Astro 的核心卖点是**内容站点生成器**——它的设计假设是大部分页面可以在构建时生成静态 HTML，只在需要交互的地方插入动态组件（岛屿架构）。但 YukiLog 是一个 API 驱动的 CMS。文章内容在数据库里，每次访问都要请求后端。"构建时生成"这个假设从根基上就不成立。结果是，我在一个为静态站点设计的框架里，手动把每个页面标记成"不要预渲染"。数据加载写在 `.astro` 文件的 frontmatter 里——那段代码夹在 YAML 分隔符和 HTML 模板之间，既不是模板，也不是脚本，是 Astro 特有的"组件顶部代码块"。 ```astro --- // 这是 Astro 的数据加载方式 // 在 frontmatter 区域直接写 await const posts = await fetchApi('/api/public/posts'); ---

{posts.map(p => )}

``` SvelteKit 的数据加载是一等公民： ```typescript // +page.server.ts — 专门为此设计的文件 export async function load({ params }) { const posts = await fetchApi('/api/public/posts'); return { posts }; } ``` 两者功能相同，但 SvelteKit 的 `load` 函数有类型推导、错误边界、数据依赖声明，是框架核心 API 而不是一个"也能用"的附带功能。其他促成迁移的因素： - **Vue 依赖**：Astro 版的交互组件用 Vue 写，意味着构建时需要同时处理 `.astro`、`.vue` 两种组件格式。Svelte 组件一种格式解决所有问题 - **脚本生命周期**：Astro 的 `

标签

YukiLog - 14 - 从 Astro 到 SvelteKit：一次不留退路的前端迁移