个人站点的内容类型通常不止一种：文章、笔记、项目、相册、书签……如果把所有内容塞进同一个集合，Schema 会变得臃肿，路由会变得混乱，维护成本会随内容量增长而急剧上升。更好的做法是为每种内容类型建立独立的模块。
模块化的具体含义
在 Astro 的语境下，模块化意味着：
- 独立的 Content Collection：每种内容类型有自己的目录和 Schema。
- 独立的路由：每种内容类型有自己的列表页和详情页。
- 独立的生命周期：文章需要发布日期，笔记需要状态字段，项目需要技术栈和链接。
本博客的模块划分
| 模块 | Schema 特有字段 | 路由 | 生命周期 |
|---|---|---|---|
| 文章（posts） | category |
/posts/ |
发布后不变 |
| 笔记（notes） | topic, status, lastUpdatedAt |
/notes/ |
seed → growing → evergreen |
| 项目（projects） | status, relatedLinks, technologies |
/projects/ |
持续维护 |
| 相册（galleries） | images（含 responsive） |
/gallery/ |
拍摄后入库 |
模块间的共享
虽然每个模块独立，但有些逻辑是共享的：
- 基础 Schema：
title,summary,publishedAt,tags,draft是所有模块共有的。 - 内容过滤：
getPublicContent函数适用于所有模块。 - 阅读时间估算：
estimateReadingMinutes不区分内容类型。 - 标签系统：
TagList组件适用于所有模块。
这种“独立但共享”的模式让每个模块可以独立演进，同时避免重复代码。
模块化的实际好处
- Schema 清晰：每种内容类型只包含它需要的字段，不会出现“这个字段只对某些内容有意义”的情况。
- 路由独立：修改相册的布局不会影响文章页面。
- 生命周期明确：笔记有状态流转（seed → growing → evergreen），文章没有，这种差异在 Schema 中就能体现。
- 易于扩展：如果未来需要新增“书签”类型，只需创建新的集合和路由，不影响现有模块。
模块化的代价
- 初始设置成本：每种内容类型需要单独的 Schema、路由和组件。
- 跨模块查询：如果需要在首页同时展示文章和笔记，需要分别查询两个集合。
- 一致性维护：修改共享逻辑时需要确保所有模块都兼容。
对于个人博客来说，这些代价是值得的。内容量不会大到需要极致优化，但模块化带来的清晰性会随着内容增长而越来越有价值。
本笔记的状态
这是一个 evergreen 状态的笔记，记录了当前已经验证的设计模式。随着站点内容增加，可能会补充更多关于模块间交互的细节。
评论