这个测试文章用于验证个人站第一阶段的内容发布链路：作者在本地维护 Markdown，推送到独立私库，服务器拉取文件，站点读取并渲染正文。
为什么使用独立仓库
内容与站点代码的变化频率不同。独立仓库让写作过程保持简单，也避免为了修改一处文字重新发布整套应用。
Git 仓库保存原稿，站点数据库负责检索与关联，页面请求负责读取正文。
这条边界意味着：
- Markdown 是正文的唯一来源。
- SQLite 不保存正文副本。
- 文章版本由 Git 历史人工管理。
content/中的文件默认公开。
第一阶段流程
- 在 Obsidian 中写作。
- 将待发布内容整理为标准 Markdown。
- 提交并推送到
main。 - 服务器执行快进拉取。
- 站点同步元数据并渲染文件。
| 环节 | 负责内容 | 不负责内容 |
|---|---|---|
| Git 私库 | Markdown、图片、修改历史 | 页面查询 |
| SQLite | 标题索引、路径、章节关系 | Markdown 正文 |
| Next.js | 读取、转换和展示 | 编辑原稿 |
GFM 渲染检查
下面的内容用于检查 GitHub Flavored Markdown：
- 普通列表
- 任务列表
-
删除线 - 后续加入正式文章
type PublishedWriting = {
title: string
relativePath: string
language: 'zh-CN' | 'en'
}
站点渲染器应对正文保持只读，并由主站样式控制标题、段落、表格、代码块和图片的视觉表现。
当前边界
第一阶段不解析 Obsidian 双链、附件嵌入、Callout、Dataview 或 MDX。需要发布的文章应先转换为标准 Markdown，这能让读取和渲染流程保持可预测。