先确定问题，再选工具#
这个站真正要解决的事情很具体：文章要好写、作品要好看、推荐要有上下文；内容要能在 Git 里管理，发布不能依赖我手动登录服务器；站点要能放在自己的 VPS 上，出了问题也能看懂、能恢复。
因此我没有从「哪个框架最热门」开始，而是先把不需要的东西删掉：首版不做评论、不接数据库、不做复杂的用户系统，也不为了看起来像平台而增加后台功能。
为什么离开 WordPress#
上一版站点是自托管的 WordPress。它把我带进门——第一次把域名、反向代理和 HTTPS 完整串起来，都是围绕它完成的，这段经历我不后悔。但用得越久越发现，写作这件事在它那里很重：文章存在数据库里，备份靠导出，主题和插件各有自己的升级节奏；服务器上还常驻着 PHP 和 MySQL，隔一段时间就要为安全更新操心一次。
真正让我下决心的是一个反差：这个站的内容本质上就是一堆文章和图片，是静态的；托管它的却是一整套动态运行时。我为动态能力付出的维护成本，换来的功能几乎用不上。既然内容是静态的，托管方式也应该回到静态。
当前技术栈#
Astro：让内容回到构建期#
文章、作品和推荐都用 Markdown 管理，由 Astro Content Collections 在构建时校验 frontmatter、生成页面和索引。同类静态框架不少，选 Astro 看重的正是这层构建期校验：字段写错、日期格式不对，构建时就报错，而不是上线后某个页面悄悄空一块。对个人站来说，静态输出带来的稳定性也比运行时灵活性更重要：页面没有应用服务器状态，访问路径也更容易缓存。
GitHub：版本管理和内容发布入口#
内容文件进入 Git 后，每次修改都有记录，可以回退，也可以在提交前审阅。后台使用 Sveltia CMS，保存内容时直接提交主分支；GitHub webhook 负责通知 VPS 构建和发布，不再需要手动 SSH 上去复制文件。
VPS、Nginx 与 systemd：把上线当成服务管理#
Astro 负责生成站点，Nginx 负责对外入口，systemd 负责守护 OAuth 和部署 webhook。每个进程做一件事，故障范围容易定位，配置也能从部署文件里复现。
静态站其实有更省事的去处，GitHub Pages 或托管平台都行。仍然放在自己的 VPS 上，是因为服务器运维本身就是我要练的能力：Nginx、systemd、发布与回滚，交给平台就没得练了。代价是出了问题要自己兜底——而自己兜底，恰恰是练习的那部分。
GitHub OAuth：只给站主人的后台#
后台不是开放注册的 CMS。登录按钮跳转到 GitHub 官方授权页，回调后服务端读取账号的固定用户 ID，只有我的账号可以继续使用 Sveltia。GitHub 负责确认身份，内容仍然落在仓库里。
这套选择的优点#
第一是边界清楚。公开页面是构建产物，后台只是提交内容的入口，OAuth 也只负责身份确认。
第二是迁移成本低。Markdown、图片和配置都在仓库里，不把文章锁在某个 SaaS 数据库；以后即使换主题，内容也不需要重写。
第三是适合我的规模。单台 VPS、一个站点、一个维护者，不需要提前引入数据库、队列、复杂监控和多副本部署。简单不是缺少能力，而是让每一层都值得被我理解。
我接受的代价#
这套方案不是没有代价。发布依赖 GitHub，静态站不适合实时互动，内容管理也不会像大型 CMS 一样提供多人协作和复杂审核。但这些不是当前阶段的问题，提前为它们付费只会增加维护面。
现在这套技术栈能让我把时间放回文章、作品和判断本身。等规模真正改变，再让问题推动下一次选型。