我为什么选择 Hexo：从 WordPress 到静态博客的思考

前言

这个博客最初是用 WordPress 搭建的，用了大概一年时间。后来决定迁移到 Hexo，从动态博客转向静态博客。

这篇文章记录了我做这个决定的心路历程，包括为什么会迁移、迁移过程中遇到的挑战、以及使用 Hexo 后的体验。

从 WordPress 说起

2024 年初，我决定开始写技术博客，想快速搭建一个看起来还不错的网站。

选择 WordPress 的原因

当时选择 WordPress 很简单：

1. 生态完善：插件、主题、教程一应俱全
2. 上手简单：不需要编程知识，后台操作很直观
3. 功能强大：评论、搜索、SEO、社交媒体集成都很方便
4. 社区支持：遇到问题很容易找到解决方案

WordPress 体验

刚开始用 WordPress 还挺顺手的：

• 后台管理界面友好，写文章、分类、标签都很直观
• 插件生态强大，想要什么功能基本都能找到插件
• 主题很多，选了一个看起来还不错的科技风主题

但用了一段时间后，慢慢发现了一些问题。

遇到的问题

问题 1：性能瓶颈

WordPress 是动态网站，每次访问都要查询数据库、渲染页面。

• 页面加载速度慢，特别是流量上来后
• 数据库查询频繁，对服务器压力大
• 需要配置缓存插件，但效果有限

问题 2：安全风险

WordPress 是黑客攻击的主要目标之一：

• 需要定期更新核心、插件、主题
• 安全漏洞频发，一个不注意就可能被黑
• 需要配置防火墙、备份插件等安全措施

有一次博客被植入了恶意代码，虽然很快清理了，但还是很影响心情。

问题 3：维护成本高

虽然 WordPress 容易上手，但维护起来并不轻松：

• 定期更新插件和主题，担心兼容性问题
• 备份、恢复流程需要仔细维护
• 偶尔会出现插件冲突，需要排查

问题 4：灵活性不足

WordPress 的灵活性是靠插件堆出来的：

• 想要自定义功能要么写代码，要么找插件
• 插件太多会让网站变慢，也增加安全风险
• 主题定制受到框架限制

接触静态博客

大概在 2024 年年中，我了解到了静态博客（Static Site Generator）的概念。

什么是静态博客？

静态博客是预先生成所有 HTML 文件，不需要数据库，也不需要在服务器端动态渲染。

特点：

• 访问快：直接返回静态 HTML，无需数据库查询
• 安全：没有动态脚本，几乎不存在安全漏洞
• 便宜：可以免费托管在 GitHub Pages、Vercel 等
• 版本控制：所有内容都是 Markdown 文件，可以用 Git 管理

静态博客选型对比

当时看了几个主流的静态博客生成器：

特性	Hexo	Hugo	Jekyll
语言	JavaScript	Go	Ruby
构建速度	中等	最快	较慢
插件生态	丰富	一般	丰富
中文支持	最好	一般	一般
学习曲线	低	中	中

为什么选 Hexo？

最终选择了 Hexo，主要原因：

1. 中文生态最完善

Hexo 是国人开发的，中文文档和社区支持最好：

• 官方文档有中文版
• 插件和主题对中文支持良好
• 遇到问题容易在中文社区找到解决方案

2. JavaScript 技术栈

我是前端开发，Hexo 使用 Node.js，更符合我的技术栈：

• 可以自己写插件和主题
• NPM 生态丰富，想要什么功能都能找到包
• 调试和修改方便

3. Fluid 主题很漂亮

Hexo 的主题很丰富，我一眼就相中了 Fluid 主题：

• 设计现代，符合技术博客的气质
• 功能完善，开箱即用
• 配置灵活，可以深度定制

4. 学习成本低

相比 Hugo 和 Jekyll，Hexo 的学习成本最低：

• 文档清晰易懂
• 常用功能都有官方插件
• 配置文件是 YAML，容易理解

迁移过程

第一步：安装 Hexo

npm install -g hexo-cli
hexo init myblog
cd myblog
npm install

第二步：安装主题

cd themes
git clone https://github.com/fluid-dev/hexo-theme-fluid.git fluid

然后配置 _config.yml：

theme: fluid

第三步：迁移内容

这是最耗时的部分。WordPress 的文章在数据库里，需要导出成 Markdown：

1. 安装插件

   npm install hexo-migrator-wordpress --save

2. 导出 WordPress XML

   • 在 WordPress 后台导出为 XML 文件
   • 包含文章、页面、评论、分类等所有数据

3. 执行迁移命令

   hexo migrate wordpress <path/to/wordpress.xml>

4. 手动调整

   • 导出的文章格式可能不完美
   • 需要手动调整 Markdown 格式
   • 图片路径需要重新处理

第四步：配置主题

Fluid 主题的配置在 _config.fluid.yml 里：

# 基本信息
index:
  slogan: "技术博客"
  highlight_theme: "atom-one-light"

# 导航栏
navbar:
  blog_title: "我的博客"
  menu:
    - { key: "home", link: "/", icon: "iconfont icon-home-fill" }
    - { key: "archive", link: "/archives/", icon: "iconfont icon-archive-fill" }
    - { key: "about", link: "/about/", icon: "iconfont icon-user-fill" }

# 页脚
footer:
  content: |
    <a href="https://hexo.io" target="_blank" rel="nofollow noopener">Hexo</a>
    &nbsp;<i class="iconfont icon-love"></i>
    &nbsp;<a href="https://github.com/fluid-dev/hexo-theme-fluid" target="_blank" rel="nofollow noopener">Fluid</a>

第五步：部署

选择了 CNB + EdgeOne Pages 的部署方案：

1. 初始化 Git 仓库

   git init
   git remote add origin <your-repo>

2. 配置部署

   deploy:
     type: git
     repo: <your-repo>
     branch: main

3. 一键部署

   hexo deploy

遇到的挑战

挑战 1：内容格式转换

WordPress 的文章在数据库里，导出成 Markdown 后格式不完美：

• 图片路径需要手动调整
• 代码块格式不一致
• 有些特殊字符需要转义

解决方案：

1. 写了个 Python 脚本批量转换
2. 逐篇检查文章，手动调整
3. 建立规范，以后用 Markdown 写作

挑战 2：评论系统迁移

WordPress 的评论在数据库里，迁移到静态博客需要重新配置。

选择了 Giscus（基于 GitHub Discussions）：

comments:
  enable: true
  type: giscus
  giscus:
    repo: jimmy367/myblog-discussions
    repo-id: R_kgDOG...

优点：

• 免费，使用 GitHub 账号登录
• 支持 Markdown 和代码高亮
• 集成到 GitHub，方便管理

缺点：

• 需要 GitHub 账号
• 不适合非技术读者

挑战 3：图片管理

WordPress 的图片在媒体库里，迁移到 Hexo 需要重新组织。

解决方案：

1. 建立统一的图片目录结构：

   source/
     images/
       posts/      # 文章配图
       covers/     # 封面图
       common/     # 通用图片

2. 使用相对路径引用：

   ![](/images/posts/example.jpg)

3. 用 Pollinations.ai 自动生成封面图（详见之前的文章）

挑战 4：SEO 配置

WordPress 有很多 SEO 插件，Hexo 需要手动配置。

解决方案：

1. 安装 SEO 插件：

   npm install hexo-generator-seo-friendly-sitemap --save

2. 配置 Canonical URL：

   canonical: true

3. 每篇文章添加描述：

   ---
   title: 文章标题
   date: 2024-01-01
   description: 文章描述，用于 SEO
   ---

迁移后的体验

性能提升明显

迁移后最直观的感受就是快：

• 页面加载时间从 2-3 秒降到 0.5 秒以内
• 首屏渲染速度显著提升
• 网站评分从 60+ 提升到 90+

维护成本大幅降低

不用再担心：

• 数据库备份和恢复
• 插件更新和兼容性
• 安全漏洞和攻击

只需要：

• 定期更新 Hexo 和主题
• 提交代码到 Git
• 运行 hexo deploy 部署

更灵活的控制

有了完全的控制权：

• 想要什么功能可以自己写插件
• 主题想怎么改都可以
• 不用受 WordPress 框架的限制

缺点也存在

当然，Hexo 也不是完美无缺的：

1. 不适合非技术用户

   • 需要会用 Git
   • 需要懂一点前端知识
   • 不像 WordPress 那样开箱即用

2. 动态功能有限

   • 没有动态页面
   • 后台管理需要自己实现
   • 不适合电商等复杂场景

3. 需要自己配置

   • SEO、评论、统计等功能都要自己配置
   • 没有 WordPress 那样的开箱即用

迁移收获

技术能力提升

迁移过程中学到了很多：

• 学会了静态博客的原理
• 掌握了 Hexo 的配置和使用
• 提升了 Git 版本控制能力
• 学习了 SEO 优化知识

思考方式的转变

从”能用就行”到”追求极致”：

• 开始关注性能优化
• 重视代码质量和可维护性
• 培养了版本控制的意识
• 学会了权衡成本和收益

建立了自己的工作流

现在写文章的流程很顺：

1. 用 WorkBuddy 生成文章内容
2. 用 Pollinations.ai 生成封面图
3. 本地预览检查
4. 提交代码到 Git
5. 自动部署到生产环境

整个过程半自动化，效率很高。

给想迁移的人的建议

如果你也在考虑从 WordPress 迁移到 Hexo，这里有一些建议：

评估迁移成本

适合迁移的情况：

• 有一定的技术基础
• 博客流量不大，不需要复杂功能
• 愿意花时间学习新工具
• 追求更好的性能和体验

不适合迁移的情况：

• 完全不懂技术
• 博客有复杂的动态功能
• 没有时间学习新工具
• WordPress 已经满足需求

迁移前准备

1. 备份 WordPress

   • 导出完整的 XML 文件
   • 备份数据库
   • 备份所有媒体文件

2. 选择主题

   • 提前选好 Hexo 主题
   • 熟悉主题的配置项
   • 确认主题满足需求

3. 规划目录结构

   • 确定图片、文章、静态资源的存放位置
   • 建立统一的命名规范
   • 准备好迁移脚本

迁移后优化

1. 性能优化

   • 启用代码压缩
   • 优化图片大小
   • 配置 CDN

2. SEO 优化

   • 配置 Sitemap
   • 优化文章标题和描述
   • 优化 URL 结构

3. 功能补充

   • 配置评论系统
   • 添加统计代码
   • 配置搜索功能

结语

从 WordPress 迁移到 Hexo，对我来说是一次重要的技术升级。

虽然迁移过程花了不少时间，也遇到了不少挑战，但最终的收获是值得的。

• 性能更好了
• 维护成本更低了
• 控制力更强了
• 技术能力提升了

如果你也在考虑从动态博客迁移到静态博客，我的建议是：勇敢尝试，但要做好准备。

Hexo 可能不适合所有人，但对于技术博主来说，它是一个非常好的选择。

希望这篇文章的分享能给你一些参考。如果你也在用 Hexo 或者有迁移经验，欢迎交流！

---

相关文章：

• WorkBuddy 博客运营完全指南
• 用 AI 自动生成封面图：Pollinations.ai 实战记录
• Hexo 博客从零搭建指南