这是一篇为发布流程而写的测试文章。

它没有复杂的观点，也没有刻意包装的结论。它的任务很具体：确认一篇放在本地的 Markdown，能够经过 GitHub 和 Cloudflare Pages，稳定地出现在网站上。

这次要验证什么

完整的文章发布链路包含六步：

  1. 在 src/content/blog 中创建 Markdown 文件。
  2. 在本地运行生产构建，提前发现格式或内容结构问题。
  3. 把文章提交到独立分支并创建 Pull Request。
  4. 由 GitHub Actions 执行一次干净安装和 Astro 构建。
  5. 在 Cloudflare Pages 的临时预览地址检查文章列表与详情页。
  6. 合并到 main，由 Cloudflare 自动更新生产站点。

其中，draft 是发布开关。写作期间使用 draft: true，文章不会出现在公开列表中；准备发布时改为 draft: false，再进入 Pull Request 流程。

为什么先看预览

构建成功只说明代码可以生成页面，不代表内容已经适合公开。

临时预览地址让每次改动都有一个不会影响生产站点的检查空间。标题是否完整、段落是否易读、链接是否正确、手机上是否舒服，都可以在合并前确认。

这篇文章的意义

如果你正在生产站点看到这段文字，说明这条链路已经完成了第一次端到端验证：本地文件、GitHub Pull Request、自动构建、Cloudflare 预览和生产发布已经真正连接起来。

以后发布文章不再需要手动上传网页文件。写作、检查、合并，就是全部流程。