Astro 内容架构：从稳定标识到可扩展分类

一个长期博客首先需要稳定的文章身份，其次才是方便浏览的分类。文章可以移动领域、调整标题，但评论与引用不应因此失去关联。这里记录首版架构的取舍，也给未来的图形化发布工具留出清晰边界。

为什么 URL 不能承担全部身份

slug 适合人阅读，却天然会随着标题与分类变化。如果评论系统直接把 URL 当主键，一次重命名就可能制造两组讨论。首版因此同时保留两种标识：slug 负责路由，id 负责关联评论、翻译和外部数据。

interface PostIdentity {
  id: string
  slug: string
  translationKey: string
}

这个约束也让后端替换更简单：Waline 适配器只接收稳定 pageKey，博客组件无需知道评论最终落在哪个数据库。

四个领域具有同等的一级入口，每个领域再声明自己的子类。文件目录只是作者的整理习惯，真正的合法性由 schema 与配置共同检查。

src/content/posts/
├─ academic/       # 论文阅读、研究记录
├─ engineering/    # 教程、开发日志、工具
├─ life/           # 札记、旅行
└─ games/          # 评测、随想、图集

新增子类时只修改分类配置，静态路由会在构建阶段自动展开；内容误填不存在的子类则直接让构建失败。这比在页面里散落字符串更容易维护。

中文与英文的阅读速度不同，当前估算把汉字和拉丁词分别计数。设汉字数为 $C$ 、拉丁词数为 $W$ ，阅读分钟数为：

T = \max\left(1, \left\lceil \frac{C}{300} + \frac{W}{220} \right\rceil\right)

它不追求绝对精确，只要在站内保持一致，就能帮助读者判断是否适合现在打开。

文章正文、归档、标签和 RSS 都在构建时生成；只有评论、搜索交互等必要功能在浏览器中增强。即使脚本加载失败，正文与导航仍然完整可读。

设计原则：先保证内容拥有稳定、可迁移的静态表达，再叠加便利性。

首版完成后，图形化发布工具只需输出同一份 frontmatter 与 MDX，而不必改写整个站点。Git + Markdown 因而不是临时废案，而是未来编辑器可以依赖的底层协议。