先确定问题，再选工具#
这个站真正要解决的事情很具体：文章要好写、作品要好看、推荐要有上下文；内容要能在 Git 里管理，发布不能依赖我手动登录服务器；站点要能放在自己的 VPS 上，出了问题也能看懂、能恢复。
因此我没有从「哪个框架最热门」开始，而是先把不需要的东西删掉：首版不做评论、不接数据库、不做复杂的用户系统，也不为了看起来像平台而增加后台功能。
这不是对 WordPress 和动态网站的普遍结论，而是一份针对单人个人站的选型记录。多人编辑、会员、实时互动和复杂审核都可能让数据库与成熟 CMS 更合适；我的问题只是没有这些需求，却一直承担它们带来的运行时和维护成本。
为什么离开 WordPress#
上一版站点是自托管的 WordPress。它把我带进门——第一次把域名、反向代理和 HTTPS 完整串起来，都是围绕它完成的，这段经历我不后悔。但用得越久越发现，写作这件事在它那里很重：文章存在数据库里，备份靠导出，主题和插件各有自己的升级节奏；服务器上还常驻着 PHP 和 MySQL，隔一段时间就要为安全更新操心一次。
更关键的是物理资源的残酷挤压：在一台 1 核 1G 的轻量 VPS 上，WordPress + PHP-FPM（常驻约 180MB）+ MySQL 8（常驻约 240MB）+ Nginx 运行时吃掉了超过 450 MB 的常驻内存。当偶尔遭遇爬虫高频扫盘或插件后台更新时，内存瞬间逼近 1GB 警戒线，甚至触发 Linux OOM Killer 强行杀掉数据库进程导致 502 白屏。
真正让我下决心的是一个反差：这个站的内容本质上就是一堆文章和图片，是静态的；托管它的却是一整套动态运行时。我为动态能力付出的维护成本，换来的功能几乎用不上。既然内容是静态的，托管方式也应该回到静态。
迁移前后真正改变的不是页面外观，而是内容、发布和恢复的边界：
| 维度 | WordPress 阶段 | Astro 阶段 |
|---|---|---|
| 内容来源 | MySQL 中的文章与后台配置 | 仓库中的 Markdown、图片和配置 |
| 内存常驻 | PHP + MySQL 占据 450 MB+ | Nginx 纯静态服务仅需 ~15 MB（降幅 95%） |
| 发布方式 | 登录后台更新，运行时立即读取 | 提交 Git，GitHub Actions 编译后直推产物 |
| 运行依赖 | PHP、数据库、主题与插件 | Nginx 静态文件，加少量独立管理服务 |
| 回退方式 | 数据库、文件和插件状态需要一起处理 | 回到已验证提交或秒级切换上一代软链接产物 |
| 主要风险 | 漏洞、插件兼容、数据库与运行时故障 | 构建失败、发布链路和外部平台依赖 |
当前技术栈#
Astro：让内容回到构建期#
文章、作品和推荐都用 Markdown 管理，由 Astro Content Collections 在构建时校验 frontmatter、生成页面和索引。同类静态框架不少，选 Astro 看重的正是这层构建期校验：字段写错、日期格式不对，构建时就报错，而不是上线后某个页面悄悄空一块。对个人站来说，静态输出带来的稳定性也比运行时灵活性更重要：页面没有应用服务器状态，访问路径也更容易被 CDN 边缘节点 100% 缓存。
GitHub Actions：云端编译与产物极速直推#
内容文件进入 Git 后，每次修改都有记录，可以回退，也可以在提交前审阅。后台使用 Sveltia CMS，保存内容时直接提交主分支。
早期我们尝试过 Webhook 触发 VPS 本地拉代码编译，但在单核小机器上逐张处理 86 张高清封面（生成 498 个 WebP 切片）会吃满 CPU 近 5 分钟。我们将其升级为**云端产物直接推送（Artifact Direct Push）**架构：
Sveltia / Git push -> GitHub Actions (4核云端 Runner 极速完成类型检查与自测) -> 打包 dist.tar.gz (~30s) -> SSH Ed25519 安全直传至 VPS releases 目录 -> VPS 解包并原子切换 current 软链接 (~1s) -> 自动清理历史 release (保留最新 3 代，防磁盘膨胀) -> 健康检查验证通过VPS、Nginx 与 systemd：把上线当成服务管理#
Astro 负责生成站点，Nginx 负责对外入口，systemd 负责守护 OAuth 和部署 webhook。每次发布在独立 release 目录中安装依赖、构建和检查，成功后再原子切换 current 软链接；如果切换后的健康检查失败，部署脚本恢复上一版本。每个进程只做一件事，故障范围容易定位，发布状态也能从仓库中的服务和部署文件复现。
静态站其实有更省事的去处，GitHub Pages 或托管平台都行。仍然放在自己的 VPS 上，是因为服务器运维本身就是我要练的能力：Nginx、systemd、发布与回滚，交给平台就没得练了。代价是出了问题要自己兜底——而自己兜底，恰恰是练习的那部分。
GitHub OAuth：只给站主人的后台#
后台不是开放注册的 CMS。登录按钮跳转到 GitHub 官方授权页，回调后服务端读取账号的固定用户 ID，只有我的账号可以继续使用 Sveltia。GitHub 负责确认身份，内容仍然落在仓库里。
这套选择的优点#
这套选择的优势可以归结为三点：公开页面只是经过验证的构建产物，后台和 OAuth 不进入读者访问链路，系统边界比较清楚；Markdown、图片和配置都在仓库里，换主题或托管位置时不需要先从某个 SaaS 数据库赎回内容；单台 VPS、一个站点和一个维护者也不需要提前引入数据库、队列、复杂监控和多副本部署。这里的简单不是缺少能力，而是让当前存在的每一层都值得被我理解和维护。
我接受的代价#
这套方案不是没有代价：内容提交和自动发布依赖 GitHub，VPS、OAuth 与 webhook 仍然需要安全更新和监控，静态站也不适合实时互动，内容管理不会像大型 CMS 一样天然提供多人协作和复杂审核。不过这些都与当前规模匹配，提前为尚未出现的问题增加数据库、队列或多套后台，只会扩大维护面。现在这套技术栈能让我把时间放回文章、作品和判断本身；等规模真正改变，再让实际问题推动下一次选型。