给博客选技术栈，本质上是回答一个问题：这台机器到底要替我省什么事，又要替我扛什么事。
我的需求很朴素：写文章、发文章、看文章。没有会员、没有评论、没有后台管理。既然如此，为什么要跑一个随时可能被扫描器盯上的动态服务？
三条硬标准
选型时我给自己划了三条线，任何方案都要先过这三关：
- 发布成本要低到无感——本地写完，一条命令推上去，不用登录服务器
- 首屏要快，且不依赖外部服务——字体、脚本、图标都不能卡住渲染
- 内容必须和代码解耦——五年后换框架，文章不能跟着陪葬
第三条是我最看重的。因为见过太多人把文章焊死在数据库里，等到要迁移那天，导出脚本写了一周。
静态生成恰好落在这三条线上
Astro 的做法是：构建时把 Markdown 渲染成 HTML，产物是一堆纯静态文件。部署时只要一个 Nginx 就能跑，连 Node 都不需要装在服务器上。
npm run build # 产物在 dist/
rsync -av dist/ deploy@server:/var/www/blog/服务器上只有 .html、.css、.webp。没有进程，没有端口，没有内存泄漏，也没有凌晨三点的告警。
代价当然也有：构建时不知道的事，它就做不到。比如实时搜索、登录状态、动态推荐，这些要么靠前端 JS 打接口，要么干脆不做。我这三样都不需要，所以代价为零。
选型不是选最强的，是选「代价落在你能承受的地方」的那个。
关于 .astro 后缀
它看起来新，但心智模型很老：上面一横线里跑数据，下面写模板。
---
const posts = await getCollection('blog');
---
<ul>
{posts.map((p) => <li>{p.data.title}</li>)}
</ul>和 Razor、和 JSP、和 PHP 是同一类东西。会写 C# 的人看两眼就能懂——这对我后面可能换 ASP.NET Core 很重要，因为视图层是重写而不是重学。
有意克制的地方
用 Astro 很容易上头，它有一堆看起来很酷的能力。但我给自己定了规矩：只把它当 Markdown 渲染器用。
- 不上 SSR adapter
- 不上 View Transitions
- 不上 Islands 交互组件
理由很实际：这些能力一旦用上，就绑死在这套技术上了。而博客的核心资产是文章，不是框架。