对个人技术博客来说，Obsidian 更适合做写作界面，不适合直接当发布系统

很多人希望把 Obsidian 直接接成发布系统，这个想法很自然，因为它确实是一个非常顺手的写作界面。

但如果目标是长期维护技术博客，我更愿意把 Obsidian 放在“写作层”，而不是“生产层”。

为什么 Obsidian 适合写，不适合直接上线

Obsidian 的优势非常明确：

• 草稿写起来快
• 双链和附件整理方便
• 适合积累碎片再收束成文章

问题在于它默认站在作者视角工作，不是站在公开站点视角工作。

公开博客在上线前还要额外考虑：

• frontmatter 是否完整
• 分类是否正确
• 摘要是否可用于归档页
• 图片路径是否适合公开访问
• 草稿内容是否应该暴露

这些事情如果完全交给笔记系统自发生成，最后大概率会重新把工程边界做模糊。

更稳的方式是“Obsidian 写，Astro 发”

我现在更认同的结构是：

1. 在 Obsidian 里持续写草稿。
2. 通过脚本把当前笔记导入博客工程。
3. 在导入阶段补齐 frontmatter、图片路径和分类字段。
4. 再由站点构建流程统一发布。

这相当于把写作自由度和上线纪律拆开。

作者在写的时候不必一直盯着目录结构，站点在发的时候也不会直接暴露原始笔记状态。

这条链路真正解决的是什么

它解决的不是“少复制一次文件”，而是下面两个更关键的问题：

内容可以继续按作者习惯生长

你不需要为了博客结构，反过来牺牲平时的记录方式。

发布仍然有单一事实来源

真正上线的内容，以 Astro 工程里的 Markdown 为准，而不是以某个随时会改的笔记目录为准。

结语

Obsidian 最适合做个人写作工作台，Astro 更适合做公开站点的交付层。

把这两层拆开，不是流程变重，而是让博客以后还能继续长。