用 Astro 重建博客：为什么我最终放弃了 WordPress

三年前我用 WordPress 搭了这个博客。装主题、装插件、调样式，折腾了整整一周，然后写了十几篇文章就停了。真正让我下决心迁移的，不是速度也不是审美，而是每次想写点东西，都要先更新一堆插件。

WordPress 到底哪里累

• 平均每两周有插件更新，其中至少一次会冲突
• PHP 版本升级要停机备份，一次半小时
• 数据库体积随时间膨胀，备份越来越慢
• 主题授权按域名绑定，换域名要重新买
• 评论区 99% 是垃圾评论，还得额外装插件拦截

最后一根稻草是有一次更新后整站白屏，排查发现是某个插件和主题的钩子打架。那一刻我意识到：我在维护一台服务器，而不是在写博客。

为什么是 Astro

选型时比较了四个方案：

方案	构建速度	首屏体积	学习成本	长期维护
WordPress	无需构建	中	低	高
Hexo	快	小	低	低
Hugo	极快	小	中	低
Astro	中	极小	中	低

Hexo 和 Hugo 都是成熟方案，我没选它们的原因是布局自由度。这两个框架的主题系统对结构改动不友好，想加个侧边栏模块往往要改主题源码。Astro 的组件模型让我可以像写 React 一样组织页面，同时输出的还是纯 HTML。

迁移过程

第一步：导出内容。 WordPress 有官方导出工具，输出 XML，再用脚本转成 Markdown。麻烦的是短代码和图片链接，我写了个小脚本批量替换。

第二步：重建模板。 这一步花的时间最多。我的要求是保留原来的卡片流和暗色模式，于是干脆手写了一套 CSS，没有引入任何 UI 框架。

第三步：接管评论。 从 WordPress 评论换成 giscus，基于 GitHub Discussions。好处是垃圾评论直接归零——毕竟要先有 GitHub 账号才能留言。

第四步：部署。 推到仓库，GitHub Actions 自动构建，一分钟内上线。

迁移后的变化

写作流程从「登录后台 → 等编辑器加载 → 写完点发布」变成了「新建一个 md 文件 → git push」。

# 新的写作流程就这三步
vim src/content/posts/new-post.md
git add . && git commit -m "post: 新文章"
git push

首屏体积从 1.8MB 降到 42KB，Lighthouse 分数从 68 涨到 100。

失去了什么

说点实话：

• 没有后台编辑器，得会用 Markdown 和 Git
• 没有原生评论，需要第三方服务
• 没有会员/付费阅读，静态站做不了
• 搜索要自己实现，我用了构建期生成索引的方案

但这些问题里，只有第一个是真正的门槛。而一旦跨过去，你会发现用文本文件管理内容，比用数据库更让人安心——所有文章都在 Git 里，随时能 diff、能回滚、能带走。

给想迁移的人的建议

1. 先在一篇文章上跑通全流程，别一次性迁全部
2. 图片单独放一个仓库或用图床，别塞进正文仓库
3. 保留旧链接的 301 跳转，别让搜索引擎的外链全部失效
4. 别追求「和原来一模一样」，迁移本来就是重新设计的机会

现在这个站的全部依赖只有三个 npm 包。三年后再打开，它大概率还能跑——而这正是我想要的。