先确定问题，再选工具#
这个站真正要解决的事情很具体：文章要好写、作品要好看、推荐要有上下文；内容要能在 Git 里管理，发布不能依赖我手动登录服务器；站点要能放在自己的 VPS 上，出了问题也能看懂、能恢复。
因此我没有从「哪个框架最热门」开始，而是先把不需要的东西删掉：首版不做评论、不接数据库、不做复杂的用户系统，也不为了看起来像平台而增加后台功能。
这不是对 WordPress 和动态网站的普遍结论，而是一份针对单人个人站的选型记录。多人编辑、会员、实时互动和复杂审核都可能让数据库与成熟 CMS 更合适；我的问题只是没有这些需求，却一直承担它们带来的运行时和维护成本。
为什么离开 WordPress#
上一版站点是自托管的 WordPress。它把我带进门——第一次把域名、反向代理和 HTTPS 完整串起来，都是围绕它完成的，这段经历我不后悔。但用得越久越发现，写作这件事在它那里很重：文章存在数据库里，备份靠导出，主题和插件各有自己的升级节奏；服务器上还常驻着 PHP 和 MySQL，隔一段时间就要为安全更新操心一次。
真正让我下决心的是一个反差：这个站的内容本质上就是一堆文章和图片，是静态的；托管它的却是一整套动态运行时。我为动态能力付出的维护成本，换来的功能几乎用不上。既然内容是静态的，托管方式也应该回到静态。
迁移前后真正改变的不是页面外观，而是内容、发布和恢复的边界：
| 维度 | WordPress 阶段 | Astro 阶段 |
|---|---|---|
| 内容来源 | MySQL 中的文章与后台配置 | 仓库中的 Markdown、图片和配置 |
| 发布方式 | 登录后台更新，运行时立即读取 | 提交 Git，验证后构建静态产物 |
| 运行依赖 | PHP、数据库、主题与插件 | Nginx 静态文件，加少量独立管理服务 |
| 回退方式 | 数据库、文件和插件状态需要一起处理 | 回到已验证提交或切换上一份发布产物 |
| 主要风险 | 漏洞、插件兼容、数据库与运行时故障 | 构建失败、发布链路和外部平台依赖 |
当前技术栈#
Astro：让内容回到构建期#
文章、作品和推荐都用 Markdown 管理，由 Astro Content Collections 在构建时校验 frontmatter、生成页面和索引。同类静态框架不少，选 Astro 看重的正是这层构建期校验：字段写错、日期格式不对，构建时就报错，而不是上线后某个页面悄悄空一块。对个人站来说，静态输出带来的稳定性也比运行时灵活性更重要：页面没有应用服务器状态，访问路径也更容易缓存。
GitHub：版本管理和内容发布入口#
内容文件进入 Git 后，每次修改都有记录，可以回退，也可以在提交前审阅。后台使用 Sveltia CMS，保存内容时直接提交主分支；GitHub Actions 先执行类型检查、构建、链接和页面自测，只有工作流成功后，签名的 workflow_run webhook 才通知 VPS 构建并激活对应提交。发布链路因此不是“提交即覆盖线上文件”，而是：
Sveltia / Git push -> GitHub main -> Actions 验证 -> workflow_run webhook -> VPS 构建独立 release -> 健康检查 -> 切换 current 软链接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 一样天然提供多人协作和复杂审核。不过这些都与当前规模匹配，提前为尚未出现的问题增加数据库、队列或多套后台，只会扩大维护面。现在这套技术栈能让我把时间放回文章、作品和判断本身；等规模真正改变，再让实际问题推动下一次选型。