从 Jekyll 到 Astro：我的博客系统为什么要做架构分离
我折腾博客很多年了。
一开始用 Jekyll，后来试过 Hexo，又换到 Hugo，再到 Next.js 博客，直到现在基于 Astro / AstroWind 重建。表面上看，这是一个不断换静态站点生成器和前端框架的过程；但回头看，真正变化的不是“哪个框架更好”，而是我对博客这件事的理解变了。
早期我关心的是：怎样最快拥有一个能访问、能写文章、能部署的个人站点。
现在我更关心的是：长期知识库里的材料，怎样经过筛选、改写、检查，再安全地变成公开博客文章。
这两个问题看起来都叫“搭博客”，但它们其实不是同一个问题。
第一阶段：博客仓库就是写作中心
Jekyll、Hexo、Hugo 这一类静态博客方案很适合早期个人博客。
那时的博客结构通常很直接：文章 Markdown 放在博客仓库里，主题、配置、静态资源和部署脚本也都在同一个仓库里。写完文章，提交代码，构建站点，发布上线。
这种方式的好处很明显：
- 概念简单，文章在哪里，站点就从哪里构建。
- 纯静态输出，部署成本低。
- 框架和主题已经解决了大部分页面问题。
- 对个人博客来说，维护成本可控。
Jekyll 胜在和 GitHub Pages 的天然关系，Hexo 对前端开发者更友好，Hugo 的构建速度和静态输出能力很强。每次迁移，都是在寻找更顺手的工具：更快的构建、更好改的主题、更熟悉的生态、更少的部署摩擦。
但这个阶段有一个默认前提：博客仓库就是写作中心。
文章的源文件、站点框架、主题配置和发布流程都放在一起。只要写作量不大、内容边界简单，这没有什么问题。
问题出现在后面：我的真正写作源头不再是博客仓库，而是私有知识库。
第二阶段：Next.js 解决的是站点能力
后来我转向 Next.js 博客，是因为想要一个更现代、更可定制的个人站点。
Next.js 的优势很清楚：React 生态成熟，组件化能力强，Vercel 部署路径短，SEO、路由、页面交互、图片优化、评论系统这些能力都能比较完整地拼起来。相比传统静态博客，它更像一个真正的 Web 应用。
这一步解决的是“站点能力”的问题。
我可以更自由地控制页面结构、交互细节、部署方式和周边功能。对于一个从无到有的现代博客来说，Next.js + Vercel 是很顺的一条路。
但它仍然没有真正解决后来的核心问题：我的写作材料越来越多地沉淀在 Obsidian 里，而不是沉淀在博客仓库里。
私有知识库和公开博客之间不是简单的复制关系。知识库里会有未完成想法、内部链接、项目上下文、私人判断和不适合公开的材料。如果博客系统直接把这些内容当作发布源，边界就会变得很脆弱。
所以 Next.js 阶段让我意识到一件事：博客系统不只是一个站点工程，它也是一个内容发布系统。
如果只关注框架和部署，就会把真正重要的问题藏起来：哪些内容可以公开，哪些必须留在私有知识库里，哪些需要改写成面向读者的文章。
第三阶段：Astro 更适合内容型站点
现在这套 Astro / AstroWind 方案，并不是因为 Astro 在所有意义上都“比 Next.js 更好”。
更准确地说，是它更适合我现在这个阶段的博客问题。
我的公开博客主要是内容型站点，不需要把每一页都做成复杂 Web 应用。Astro 的内容驱动模型、静态构建、Markdown / MDX 支持和 Island 架构，天然更贴近“文章站点”的需求。AstroWind 则提供了一套现成的博客结构，让我不用从零重新搭页面、SEO、列表、分类和基础样式。
但这次真正关键的变化，仍然不是从 Next.js 换到 Astro。
真正关键的是：我不再让博客框架直接成为写作源头。
现在的架构：把四件事分开
现在这套博客发布系统分成四层：
私有知识库
-> 发布中间层
-> Astro 博客构建仓库
-> GitHub Pages 静态产物每一层只做自己的事。
私有知识库负责沉淀原始材料。这里可以保留项目笔记、内部链接、未完成判断、私人上下文和长期知识结构。它首先服务于思考，不服务于博客框架。
发布中间层负责保存准备公开的文章副本。文章进入这里之前，需要经过筛选、脱敏、改写和 frontmatter 检查。这里的文章不是长期主版本，而是面向公开发布的副本。
Astro 博客仓库负责站点构建。它维护 AstroWind 框架、路由、样式、内容读取配置和构建流程，但不保存私有知识库的完整内容。
GitHub Pages 只负责托管最终静态产物。上线的是构建后的 HTML、CSS 和 JS，而不是我的原始 Markdown 知识库。
这套结构比“把文章直接放进博客仓库”多了一层，但这层正是现在最重要的部分。
为什么一定要有发布中间层
如果没有发布中间层，私有知识库和公开博客之间就只剩两种粗糙选择：
一种是把知识库直接接进博客构建流程。这样看起来自动化程度高，但风险也高：私有上下文、未公开判断、内部链接和不完整内容都可能被误带进发布链路。
另一种是在博客仓库里重新维护一份文章。这样边界清楚一些，但长期会变成两套源头：知识库一份，博客仓库一份。时间久了，文章来源、改写状态和发布状态都会变得难追踪。
发布中间层的价值，就是在二者之间放一个人工可检查的缓冲区。
一篇文章只有准备公开时，才进入发布副本目录。进入之后，它就按公开读者的标准来处理：标题是否清楚，摘要是否独立，内部链接是否清理，语境是否完整，是否还有不该公开的信息。
这样，私有知识库可以继续按照长期思考的方式组织，博客站点也不用反过来要求知识库迁就它的目录和字段。
框架迁移背后的真正变化
回看这条路线，Jekyll、Hexo、Hugo、Next.js、Astro 分别解决了不同阶段的问题。
Jekyll 让我拥有最早的静态博客入口。Hexo 和 Hugo 让我在静态博客生态里寻找更顺手的写作和构建体验。Next.js 让我把博客看成一个更完整的现代 Web 站点。Astro 则把问题重新拉回到内容本身：一个文章为主的站点，应该尽量轻、静态、可维护。
但最重要的变化不是工具表上的迁移，而是边界意识的成熟：
- 写作源头不等于发布源头。
- 私有知识不等于公开文章。
- 博客框架不应该决定知识库结构。
- 远端构建系统不应该直接接触未经筛选的私有材料。
- 真正值得自动化的是清楚的发布流程，而不是把所有内容无差别推向公开。
这也是为什么我现在更愿意把博客系统理解成一个“带隔离层的静态发布系统”，而不是一个单纯的 Astro 站点。
小结
从 Jekyll 到 Astro，我一路换过很多方案。每一次迁移都解决了当时最痛的问题，但也暴露出下一层问题。
最早的问题是“我怎样拥有一个博客”。后来变成“我怎样拥有一个现代博客”。现在的问题则是“我怎样把长期知识库里的内容安全、清楚、可重复地发布出去”。
AstroWind 只是当前用来生成公开站点的框架。真正稳定下来的，是这套分层思路：私有知识库负责沉淀，发布中间层负责检查和改写，Astro 负责构建，GitHub Pages 负责托管结果。
博客最终呈现在读者面前的是一篇篇文章。但在文章背后，更重要的是边界：什么留给自己，什么可以公开，什么需要改写之后再公开。