每次想搭一个个人博客，最容易掉进的陷阱就是“先造一套复杂的系统，最后却没写几篇文章”。在做这个网站之前，我也犹豫过要不要直接用 Next.js 或一套带后台的 CMS；但很快意识到，内容型网站最重要的事情只有一件：让读者快速抵达文字，同时让我自己打开编辑器就能写。
这也是我最终选择 Astro 的原因。它没有把一个简单的博客变成庞大的单页应用（SPA），而是把重心放回了 HTML 和 Markdown 本身。
静态优先：把复杂度留在构建期
对于以技术文章和项目复盘为主的个人网站来说，90% 以上的页面在发布之后都不会频繁变动。如果每次读者打开一篇文章，浏览器都要先加载一整套前端运行时、请求接口、再在客户端拼装 DOM，不仅首屏变慢，维护状态同步也是额外的负担。
Astro 的“默认零客户端 JavaScript”策略刚好切中了这个痛点：所有文章页、分类归档和 RSS 都在构建阶段直接编译成干净的静态 HTML。部署到服务器上之后，Nginx 只需要做最简单的静态文件分发，既省去了生产环境的 Node.js 进程维护，也让页面几乎在点击瞬间就能完成渲染。
Markdown 内容集合：让写作回到纯文本
过去用本地 Markdown 写博客，最怕的是文章多了之后 frontmatter 字段乱掉——比如某一篇漏写了日期、或者把分类名拼错，等到上线后才发现列表页渲染报错。
Astro 的 Content Collections（内容集合）用一套轻量但严格的 schema 解决了这个问题。现在我写文章只需要关心两件事：
- 在正文中专注写 Markdown：无论是建模思路推导、代码块还是结构图，都可以直接按习惯排版，和代码放在同一个 Git 仓库里版本管理；
- 让构建工具替我检查元信息：标题、摘要、发布日期、中英文标记（
zh/en）以及草稿状态（draft）都在编译时自动校验，漏填或类型不对会直接在终端报错，不会把半成品带到线上。
按需交互：只在真正需要的地方写 JS
选择静态生成，并不代表网站只能是一张死板的传单。在这个博客里，我依然放进了明暗主题切换、中英文界面切换，甚至还塞进了一个背法语单词和练动词变位的小工具。
区别在于，这些交互只挂载在真正需要它们的组件上，不会污染整篇文章的阅读流。对我来说，这种“默认静态、按需动态”的边界感非常舒服——它提醒我把精力花在打磨文章内容上，而不是无休止地折腾前端脚手架。