从 Wagtail 迁移到 Astro(一):为什么要迁移与选型过程
· 约 9 分钟阅读
Last updated on

从 Wagtail 迁移到 Astro(一):为什么要迁移与选型过程

作者: Alex Xiang


本系列记录将 ZiCode 博客从 Wagtail(Django CMS) 迁移到 Astro 静态站点的完整过程,包括动机、选型、迁移阶段、日常写作与上线。本文为第一篇:为什么要迁移,以及选型过程。

一、为什么要迁移

1.1 原有架构的痛点

本站此前使用 Wagtail 作为 CMS,后端是 Django + SQLite,部署在单机服务器上。运行几年后,逐渐暴露出一些痛点:

  • 运维成本:需要维护 Python 环境、数据库、静态文件与媒体文件,升级 Django/Wagtail 时偶有兼容性问题。
  • 资源占用:即使访问量不大,常驻进程与数据库仍会占用内存与磁盘。
  • 发布流程:内容在后台编辑后发布,若希望「用 Git 管理文章」或「本地写 Markdown 再发布」,需要额外打通流程。
  • 前端灵活度:Wagtail 模板与前端技术栈相对固定,想做深色模式、站内搜索、更自由的版式时,改造成本较高。

因此希望将博客改为 以内容文件为核心、构建时生成静态站 的模式,在保证内容不丢失的前提下,降低运维成本、简化发布方式。

1.2 迁移的目标

  • 内容延续:历史文章、分类、标签、专栏、发布时间等尽量保留,URL 结构可读且稳定。
  • 写作方式:新文章用 Markdown 编写,放入版本库,与代码一起管理。
  • 静态输出:构建得到纯静态 HTML/CSS/JS,可部署到任意静态托管或当前服务器。
  • 体验提升:支持深色模式、站内搜索、更好看的版式与头图展示。

二、选型过程

2.1 静态站点生成器(SSG)候选

考虑过的方案包括:

方案优点顾虑
Hugo速度快、生态成熟、主题多模板语法(Go template)与现有前端技术栈不一致,定制需学一套新东西
ZolaRust 生态、配置简单、之前写过 Zola 教程与当前希望用的前端技术栈(React/组件化)不太一致
Next.js(静态导出)与 React 生态一致对纯内容站偏重,构建与部署相对「大」
Astro内容优先、Markdown/MDX 原生、可混用 React 等、构建输出轻量相对较新,但文档与社区已足够

2.2 为什么选择 Astro

最终选择 Astro 的主要原因:

  1. 内容优先:Content Collections 与 Markdown/MDX 是一等公民,frontmatter 可校验(Zod),和「用文件管文章」的思路非常契合。
  2. 零 JS 默认:默认输出静态 HTML,交互按需加(如搜索、主题切换),首屏与可访问性更好。
  3. 技术栈灵活:若将来某块需要 React/Vue 组件,可以按需引入,迁移路径清晰。
  4. 构建与部署简单astro build 得到 dist/ 静态目录,可 rsync/SCP 到现有服务器,或接到 CI/CD 做自动发布。
  5. 与现有资产兼容:可从 Wagtail 导出 Markdown 与媒体路径,通过脚本批量生成 Astro 所需的内容文件与资源路径。

综合「迁移成本、后续维护、扩展性」几方面,Astro 比较符合「长期积累的中文技术博客」的定位。

2.3 与其它方案的简单对比

  • Hugo:构建极快、主题丰富,但定制需要熟悉 Go template 和 Hugo 的 content type;若团队以 React/Vue 为主,学习成本不低。
  • Zola:Tera 模板、配置简洁,本站曾写过 Zola 教程;若不做复杂交互,Zola 也够用,但 Astro 的 Content Collections + 组件化更贴近现代前端习惯。
  • Next.js 静态导出output: 'export' 可生成纯静态站,但 Next 的默认心智是「应用」而非「内容站」,路由、数据拉取、图片优化等配置较多;对纯博客而言略显重。
  • Astro:从设计上就是「内容优先 + 按需交互」,文档里对 Markdown、frontmatter、集合的说明很完整,上手快。

三、迁移前需要想清楚的事

  • URL 是否要保持一致:若旧站已有外链或搜索引擎收录,建议新站文章 URL 与旧站一致(如 /blog/<slug>/),必要时在 Nginx 或旧站做 301 到新地址。
  • 评论与统计:若原来用第三方评论或统计,迁移后需重新接入或改用新方案(如 Giscus、Umami 等)。
  • RSS:Astro 可生成 RSS,需保证 feed 地址不变或做好重定向,方便订阅者无感切换。

四、本系列文章结构

后续文章将按实际迁移顺序展开:

确定选型后,下一步就是拆解迁移工作、按阶段执行。下一篇将具体讲 迁移的几个阶段 与实施顺序,包括数据同步、内容转换、URL 设计和验证清单。