重新建站，我为什么选了 Halo，以及踩过的那些坑

旧站跑了好几年，后台越用越沉，插件之间打架，每次升级都像开盲盒。终于在一个周末下定决心：推倒重来。选型转了一圈，最后落到了 Halo 上。这篇文章不打算写成官方文档的搬运，只记录一个普通站长从决定换系统到站点重新上线的完整过程——哪些地方顺手，哪些地方骂骂咧咧，哪些坑你大概率也会遇到。

为什么是 Halo，而不是 WordPress 或 Hexo

先说结论：我需要的是一套后台能好好写字、数据在自己手里、又不必天天 SSH 折腾的方案。

WordPress 功能确实全，但跑久了像个庞然大物。插件一多就开始互相打架，升级一次心惊胆战，之前那个站还被挂过两次马，实在烦了。静态生成器如 Hexo 够轻，可每次发文都要本地构建再推送，换个主题还得改模板，对“打开浏览器就想写两句”的场景不够友好。Halo 卡在中间：它是自托管服务，有正经的后台，Markdown 和富文本都支持，编辑器顺手，同时又有插件市场，不用什么都自己写。

另一个让我下定决心的细节是 Halo 的版本节奏。社区版完全开源免费，个人使用功能足够，付费版面向商业场景，不买也不影响你用核心功能。对于一个“重新建站”的人来说，起步成本低、后续不被绑架，这很重要。

部署：Docker Compose 是首选，别跟 H2 较劲

Halo 的部署方式挺多，Docker Compose、宝塔面板、1Panel、单容器 docker run 都行。我选的是 Docker Compose + PostgreSQL，这是官方推荐的生产级组合。

核心配置不复杂，关键是别用默认的 H2 数据库。H2 拿来试水可以，但文件一旦损坏，数据很难恢复，用一位过来人的话说，“很鸡肋”。Compose 文件里把 --spring.r2dbc.url 指向 PostgreSQL，数据目录挂到宿主机，就算跑起来了。镜像拉取如果慢，换成 registry.fit2cloud.com/halo/halo 这个国内镜像源，能省不少等待时间。

如果你对命令行有心理阴影，宝塔面板的 Docker 应用商店里直接搜 Halo，填域名、点安装，也能跑起来。但要注意宝塔默认给的是社区版镜像，想升级版本或者切付费版，需要手动改镜像标签。

一个容易被忽略的坑：JVM 内存。默认 -Xmx256m -Xms256m 对 2G 小机器刚好够用，但如果你插件装得多，或者后台操作频繁，适当调到 512m 会明显减少卡顿。

数据迁移：插件能帮你搬，但别指望“无缝”

我的旧站数据不算多，但附件路径的问题几乎绕不过去。Halo 官方有 plugin-migrate 插件，支持 WordPress、Ghost、Typecho、Hexo 的 Markdown 导入，甚至能处理 RSS/Atom 订阅文件。安装后在 Console 左侧菜单会出现“迁移”入口，上传导出文件，按提示走就行。

但“搬得过来”和“搬得干净”是两件事。WordPress 的图片路径带 /wp-content/uploads，导入 Halo 后文章里的链接不会自动适配，得批量替换。我写了个 Python 脚本扫了一遍所有文章，把旧路径映射到 Halo 的新附件地址，才把图片全部救活。如果你的旧站附件量很大，这一步预留一个下午并不夸张。

另一个容易被低估的细节是评论迁移。迁移插件能保留来源的评论关系，但评论反垃圾、通知这些“配套能力”在 Halo 里需要单独装插件。搬完数据只是第一步，后面的评论治理是另一件需要花心思的事。

官方文档给了一个很实在的建议：先在本地或测试环境跑一遍导入，确认文章、页面、附件都正常，再动生产环境。导入过程会频繁请求后端和上传附件，线上环境万一网络波动或性能不足，可能出现部分数据失败，回滚起来更麻烦。

主题与插件：默认的够用，但“生态薄”是真实的代价

Halo 2.x 的默认主题 Earth 完成度比想象中高，改个配色、配张封面就能上线，不少人迁过来之后“连主题都懒得换了”。如果不想折腾，Earth 加几个基础插件就是一套干净的个人站点。

想多一点风格的话，社区里 Fluid、Sakura、iEmo 这些主题都有 Halo 版本，支持友情链接、代码高亮、瞬间、图库等插件。但这里要说一句实话：Halo 的主题和插件生态跟 WordPress 没法比。有用户直言“想找个好点的代码高亮主题都得自己改”。这不是 Halo 的致命伤，但它意味着你有时候需要接受“默认够用”而不是“应有尽有”。

插件方面，建议起步阶段只装真正用得上的几类：SEO 增强（sitemap、元数据控制）、评论系统（Waline 或 Twikoo 这类无后端方案，省心）、代码高亮（如果你写技术内容）。后台的“应用市场”插件从 Halo 2.10 开始内置，直接在 Console 里搜索安装就行，不用去 GitHub 手动下 JAR。插件装多了确实会拖慢后台，定期清理不用的，是长期使用的必修课。

性能与 SEO：别指望“装完就有人来”

Halo 是 Java/Spring Boot 应用，冷启动比 PHP 系的 Typecho 慢，JIT 预热之后才能进入正常响应节奏，缓存命中后大概 200–500ms 的量级。在 2 核 2G 的小机器上，Redis 缓存几乎是必选项——Halo 原生支持，后台启用即可，对数据库查询压力的缓解立竿见影。CDN 和图片优化则是锦上添花，尤其是文章封面和外链图片多的站点，开启缓存和懒加载之后体验差别明显。

SEO 方面，Halo 自带基础的 SEO 设置（站点关键词、描述、搜索引擎屏蔽开关），但真正让内容被收录，靠的是持续输出和 URL 结构的克制。站点标题和描述认真填，安装一个 SEO 增强插件把 sitemap 和 meta 标签管起来，剩下的就是写了。别在“优化”上花太多时间，一个没几篇文章的新站，SEO 工具再全也变不出流量。

写在最后

重新建站这件事，最耗人的往往不是“装系统”，而是迁移和适配。Halo 在这两件事上帮了大忙：后台写作体验舒服，Markdown 和图片上传不折腾，主题换起来数据不动，插件独立运行互不干扰。它不是一个完美的系统——生态厚度不如 WordPress，插件装多了后台会慢，冷启动需要耐心。但对于一个想认真写字、又不想被技术栈绑架的个人站长来说，Halo 目前是我用过最平衡的选择。

如果你也在犹豫要不要换，我的建议是：先用 Docker 在本地或测试机跑一周，把迁移插件跑一遍，把常用主题试两个。折腾一圈之后，你会很清楚它适不适合你。比看十篇评测都管用。