原触发 · 原型
个人博客重构记:从 WordPress 到 Astro
项目背景
为什么要重构?
我的博客用 WordPress 运行了5年,积累了200多篇文章。但越来越感到:
痛点:
- 性能问题:加载慢,即使用了缓存插件
- 维护成本:要更新 PHP、插件、主题,担心安全漏洞
- 编辑体验:Gutenberg 编辑器不如 Markdown 顺手
- 过度设计:我只需要静态展示,不需要动态功能
契机:
2025年底,服务器到期。我在续费前问自己:真的需要一个动态网站吗?
答案是:不需要。
技术选型
为什么选 Astro?
对比了几个方案:
| 方案 | 优点 | 缺点 | 结论 |
|---|---|---|---|
| Jekyll | 成熟、GitHub Pages 原生支持 | Ruby 生态不熟悉、构建慢 | ❌ |
| Hugo | 构建速度快 | Go 模板语法陡峭、生态较小 | ❌ |
| Gatsby | React 生态丰富 | 太重、打包体积大 | ❌ |
| Next.js | 熟悉 React、SSR 能力 | 杀鸡用牛刀,博客不需要 SSR | ❌ |
| Astro | 默认零 JS、组件化、Markdown 优先 | 相对较新 | ✅ |
最终选择 Astro,理由:
- 性能优先:默认输出静态 HTML,按需加载 JS
- DX 好:类 JSX 语法,Markdown 原生支持
- 灵活性:可以混用 React/Vue/Svelte(虽然我不需要)
实现过程
1. 内容迁移
WordPress 导出 → Markdown 转换:
# 使用 wordpress-export-to-markdown 工具
npx wordpress-export-to-markdown --post-folders=false
遇到的问题:
- 图片链接还是旧的 WordPress 路径 → 写脚本批量替换
- 部分 HTML 内容混在 Markdown 中 → 手动清理
- Frontmatter 字段需要统一 → 用正则批量修改
2. 设计与样式
原则:
- 极简设计,突出内容
- 响应式布局
- 深色模式支持
技术:
- 用 CSS 变量管理主题色
- Flexbox + Grid 布局
- 字体:思源宋体(正文)+ JetBrains Mono(代码)
3. 功能实现
核心功能:
- 文章列表与分页
- 标签筛选
- 搜索(客户端 Fuse.js)
- RSS 订阅
- Sitemap 生成
没做的功能(刻意省略):
- ❌ 评论系统(用邮件或社交媒体互动)
- ❌ 文章点赞、阅读量(不需要虚荣指标)
- ❌ 社交分享按钮(简化页面)
4. 部署
方案:Cloudflare Pages
优势:
- 免费、CDN 加速
- 自动部署(Git push 即上线)
- 自定义域名、HTTPS 自动配置
构建命令:
npm run build
部署配置:
- Build command:
npm run build - Build output directory:
dist
数据对比
性能提升
| 指标 | WordPress | Astro | 提升 |
|---|---|---|---|
| 首屏加载 | 2.8s | 0.6s | 78% |
| 页面大小 | 850KB | 120KB | 86% |
| Lighthouse | 65分 | 98分 | 51% |
成本对比
| 项目 | WordPress | Astro | 节省 |
|---|---|---|---|
| 服务器 | $10/月 | $0 | $120/年 |
| 维护时间 | ~2h/月 | ~0.5h/月 | 75% |
经验教训
做对的事
- 内容优先:先完成迁移,再优化细节
- 保持简单:只做真正需要的功能
- 自动化:脚本化重复任务(图片处理、链接替换)
踩过的坑
- SEO 迁移:忘记设置 301 重定向,损失了部分流量
- 解决:用 Cloudflare Workers 做路径映射
- 构建时间:200+篇文章,初次构建很慢
- 优化:用增量构建、图片懒加载
- 样式细节:深色模式下代码块对比度不够
- 调整:手动调整 Shiki 主题配色
后续计划
- 添加全文搜索(考虑 Pagefind)
- 优化移动端体验
- 写一篇详细的迁移教程
- 开源博客主题
总结
这次重构最大的收获:
不是技术本身,而是重新思考”我需要什么”。
很多时候,我们选择复杂方案,不是因为需要,而是因为:
- 从众(别人都在用)
- 炫技(展示自己会)
- 惯性(习惯了就懒得换)
适合自己的,才是最好的。
对于一个静态博客,简单、快速、易维护,就够了。