先说结论：不是 CMS 不好，是这台机器装不下它。
约束条件摆在这儿
服务器是 1.7G 内存的阿里云小机器，上面已经跑着一个常驻的 agent 网关，占掉 700M 上下。留给博客的余量，大概是 600M。
这个数字决定了一切。
| 方案 | 空载内存 | 在这台机器上 |
|---|---|---|
| WordPress（PHP-FPM + MySQL） | 400–600M | 装得下就别想跑别的 |
| Halo（JVM） | 400–700M | 同上，冷启动更难受 |
| Ghost（Node） | 150–250M | 勉强，但为了博客多养个进程不值 |
| 静态生成器 | 构建时占用，运行时约等于 0 | ✅ |
静态生成器最妙的地方不在”快”，在于它把成本从运行时挪到了构建时。构建是一次性的、可以在别处跑的、失败了重来一次就行；而常驻进程的成本是按秒付的，还得算上内存泄漏、依赖漏洞、半夜告警。
那为什么不用 Hugo
Hugo 更快，单二进制，几乎零依赖。如果只是写文章，Hugo 是更好的选择。
我选 Astro 的原因只有一个：Markdown 里能直接塞交互组件。
写技术文章的人迟早会遇到这个需求——想解释一个算法，文字写了八百字还是云里雾里，画个能拖动的东西三行就懂了。Hugo 做这个要跟 Go template 搏斗，Astro 就是写个组件的事。
为了一个”迟早用得上”的能力放弃几秒的构建速度，值不值？我的判断是值，因为构建慢一秒没人感觉得到，而想加交互时加不了，那种憋屈是真的。
那些”必须要有”的功能怎么办
一个博客通常被认为需要：评论、搜索、统计、图片管理。
我把它们全做成了零后端：
- 评论：giscus，数据存在 GitHub Discussions，不占我的资源
- 搜索：Pagefind，构建时生成静态索引，中文分词一般但够用
- 统计：nginx 日志自己看，不往页面上塞第三方脚本
- 图片：先放本地，量大了再上对象存储
这套组合的代价是：评论要登录 GitHub 才能发。我认为对技术博客来说这反而是好事——能过滤掉九成噪音，剩下的一成是同行。
写作流程
Markdown 放进 src/content/blog/，跑一行 bash deploy.sh。
没有后台，没有登录页，没有”数据库连接失败”。要改一个错别字，就是改一个文件、重新构建、同步。
听起来原始，但它有个隐藏好处：内容全是纯文本，十年后还能读。 换个框架、换个服务器，文件还在。
用 CMS 的人三年后最常问的问题是”怎么导出我以前的文章”，而这个问题在我这儿不存在。