项目定位#
这是我正在使用的个人网站。它把文章、作品、推荐和关于页放在同一个可检索、可归档的内容系统中，让访问者先看到内容，再决定是否继续了解作者。
设计与实现#
站点基于 Astro Narrow 深度定制，使用 Astro Content Collections 管理 Markdown 内容，Sveltia CMS 负责后台编辑，GitHub OAuth 限制后台入口，VPS 上由 Nginx、systemd 和部署 webhook 组成发布链路。
选型的核心是「内容即文件」：所有内容都是仓库里的 Markdown，Sveltia 只是编辑入口而不是另一个数据源，后台写入的结果仍然是一次 Git 提交。内容因此天然有版本、可回滚、可以在任何编辑器里修改，站点坏了也不存在「数据被锁在数据库里」的问题。
内容与发布链路#
文章、作品、推荐、普通页面和系列各自使用 typed content collection，默认语言路径保持简洁，英文内容使用独立 locale。构建阶段生成静态 HTML、RSS、sitemap 和搜索索引；浏览器端只承担搜索、主题、图库和弹窗等增强交互。
静态优先不是性能洁癖，而是运维决定：个人站的主体是读，动态面越小，需要长期守护的进程就越少。评论是唯一的例外，它通过 Giscus 挂在 GitHub Discussions 上——把动态部分外包给已有平台，站点本体仍然只是一堆可以随时重新构建的文件。
生产发布从 GitHub push 开始，部署服务只快进到远端 main，在独立 release 目录中安装依赖、类型检查、构建和检查内部链接，再用 current 符号链接原子切换。Nginx 只读取当前 release，OAuth 和 webhook 运行在分离的 systemd 服务用户下，失败时保留旧版本。
链路里的每个约束都对应一类真实故障：只快进，线上就不会出现来历不明的提交；在独立目录构建，访客就不会看到构建到一半的产物；原子切换，回滚就只是把符号链接指回上一个目录。
当前边界#
这个站点优先解决内容生命周期和可维护发布，不试图变成通用 CMS、社交平台或 SaaS。公开页面保持静态优先，后台只服务作者本人。几个「不做」也是明确的：访问统计等真实需要出现了再引入；英文内容保留独立路由，但不做低质量的批量翻译；发布渠道只有一条，不为求稳再维护第二套平行链路——备份靠的是可回滚的 release，而不是更多的发布方式。
我在这个项目里关注的事#
这里的重点不是堆叠功能，而是让内容生命周期可见：文章有版本、作品有体验入口、推荐有使用背景，发布过程可以复现，故障也有明确的排查位置。