初月_Yuechu

先静态，再交互#

大部分文章页、归档页、关于页都是纯 Astro 组件，构建时直接输出 HTML。只有真正需要响应点击和输入的部分，才会写成 Svelte 组件，并通过 hydration 指令挂载。

这三种策略的区别，本质上是在回答一个问题：这个交互最早什么时候可能被用到？

Runes 让状态更直白#

Svelte 5 的 runes 写法比过去的响应式语法更接近普通 JavaScript：

1
<script lang="ts">
2
  let query = $state("");
3
  let selectedTag = $state("");
4
  let filtered = $derived(
5
    items.filter((item) => item.title.includes(query))
6
  );
7
</script>
8

9
<input bind:value={query} />

$state 声明可变状态，$derived 声明派生值。比起手动维护依赖关系，这种写法更容易读，也更不容易漏掉更新。

一个真实的取舍#

筛选器需要读取 URL 参数，让刷新和分享后的状态保持一致。这段逻辑只能在浏览器里运行，所以放在 onMount 中；但它又不需要整个页面都变成客户端组件。

交互的边界应该由需求决定，而不是由框架决定。

我把筛选器拆成独立组件，只让它自己承担状态，页面其余部分继续静态输出。这样一来：

• 没有筛选需求的读者，不会为这段脚本付出首屏成本；
• 需要交互的读者，点开筛选器后功能完整可用；
• 构建时仍然能生成可读的 HTML，搜索引擎和 RSS 不受影响。

小结#

Svelte 5 在这个博客里不是主角，而是配角。它负责把少数需要响应的地方做得顺滑，其余部分交给 Astro 在构建时完成。这种分工听起来保守，但对内容站来说，保守往往意味着更快的首屏和更少的故障面。