与 WordPress 分手：二十年后
Source: Hacker News
Source: …
从 SiteGround 迁移到 Bluehost
去年十一月的黑色星期五期间，我把网站从 SiteGround 迁移到了 Bluehost。这并不是一次雄心勃勃的基础设施决策——两家供应商都提供共享主机。SiteGround 在续费时的费用大约是原来的五倍，而 Bluehost 则明显更便宜，并宣传 99.9 % 的正常运行时间，纸面上看起来已经足够好。对于个人网站来说，每月四十三分钟的宕机时间听起来并不是一个严重的权衡。我不需要为博客配备顶级基础设施，但我也不想收到 updown.io 发来的邮件提醒网站宕机，或者有人抱怨在阅读到一半时网站崩溃。
迁移体验
迁移过程相当痛苦。仪表盘已经相当清晰地说明了情况：网站并没有灾难性地宕机，但噪音足以不断侵蚀信心。响应时间的波动超出了我的预期，Bluehost 仍未达到其宣传的 99.9 % 正常运行时间。所有的支持交互——包括升级路径——都没有足够的技术深度来正确诊断问题。
Bluehost 确实提供了 Cloudflare 集成，至少让缓存成为可能，但该层的 bug 够多，以至于从未真正带来安心。廉价的基础设施只有在保持平淡时才算便宜；一旦开始需要关注，省下的费用就会被运维摩擦所抵消。
博客的正常运行时间仪表盘
主机迁移只是触发因素 {#the-hosting-move-was-only-the-trigger}
然而，这次迁移暴露了更深层次的不匹配。我早就知道 WordPress 已经不再完全符合我的需求。我自 2007 年起就一直在使用 WordPress，它一直表现不错。它为我提供了发布功能、管理面板、主题、插件、评论、订阅源，以及一种多年来持续写作的简便方式。我 并没有 持有某种时髦的反 WordPress 立场。它长期以来解决了正确的问题。
但我现在的网站主要是一个档案库，而不是报纸或协作出版物。它是多年跨主题、语言、情绪、时代和成熟度的写作集合。
WordPress 擅长存储文章。但就我想要的工作方式而言，它在把档案视作可以检查、重新组织、在本地搜索并有意重塑的对象方面就不那么擅长了。
我真正想要的
迁移离开 WordPress 不仅仅是因为 Bluehost。更重要的是，我希望能够以一种随着时间变得尴尬的方式来处理自己的写作。我曾在 Google Docs 中起草，然后再把所有内容复制回 WordPress。
我希望站点的行为更像是一部我可以真正检视的作品，而不是一个出版界面。一个长期运行的博客会复利（参见复利效应），和其他任何事物一样，复利只有在你能看到并使用其中内容时才有意义。
我也想更有意识地链接文章。随着时间的推移，这样的站点会产生一些看不见的关联：
- 十年前的一篇文章可能包含了我去年才真正展开的想法的种子。
- 另一篇文章可能值得写续篇、纠错或更细致的后续。
在 WordPress 中，这些链接往往是偶然出现的。
这次迁移也迫使我把站点视为数据和散文。我必须：
- 更清晰地对事物进行分类。
- 更有意图地定义类别。
- 更有意识地使用标签。
- 为相互关联的文章引入系列模型。
我们目前的进展
这正是把我推向 Yapress 的原因——它的全称是（请鼓掌），我的姓名首字母加上 “press”。这也是我不从事广告行业的原因。我使用 Codex、Claude 和 Gemini 的组合来构建它，并把它加入了我的 新发布列表。
该项目逐渐演变成一个 markdown‑first 发布设置。它支持：
- WordPress 导入
- 分类法、系列和归档
- 内容校验
我以前从未向 npm 发布过任何东西，所以这个小项目也让我达成了这个里程碑。
注意： 功能列表并不是重点。重点是站点现在以文件形式存在。我可以：
- 在本地搜索所有内容
- 在代码编辑器中编辑它
- 用 Git 进行版本管理
- 在不每次都与 WordPress 纠缠的情况下重新组织内容
我甚至添加了一个 插件系统。由于站点是完全静态的，插件只能注入代码片段，而不能在运行时执行任何动态操作——这对我的需求来说已经足够。
它还为我在迁移过程中提供了一种更简洁的方式来保留 旧 URL，这很重要，因为我不想破坏多年的链接。
权衡 {#the-trade-off}
这并非免费操作。我花了大量时间进行 vibe‑coding Yapress，在出现卡顿时介入，三次检查链接，并编写了一套脚本以确保一切按预期运行。
为什么 WordPress 仍然不错
- 成熟的管理界面
- 快速的浏览器编辑
- 庞大的生态系统
- 熟悉的约定
我放弃了什么
采用静态或 Markdown‑first 意味着失去 WordPress 的一些便利，尤其是 评论 和 订阅。我暂时放弃了评论，但我构建了一个小插件 – yapress‑mailerlite – 来处理订阅。
实际中的权衡
- 更直接的所有权 – 我掌控整个技术栈。
- 更简洁的系统 – 我更倾向于运行自己能理解的东西，而不是把理解外包给更大、更不透明的平台。
我的平台工程标准
平台只有在为用户提供一条真正优于自行构建的平坦道路时才值得保留：
- 降低摩擦
- 降低认知负荷 – 请参阅我的文章 stop‑wasting‑brainpower
- 更好的默认设置
- 更安全的操作
如果用户能够构建同样好甚至更好的路径，那么平台并没有帮助。
为什么我要重写此站点
WordPress 仍然带有平台的限制，却提供的优势更少。我重写站点并不是因为我突然在乎超大规模博客基础设施；而是因为 归档已成为主要资产，我需要一个匹配这一现实的设置。
In Consequence
我知道这看起来像是过度工程，但激励是好的。我目前选择 Next.js，因为它易于部署且我已经熟悉其工具链。以后可以迁移到 Cloudflare 的免费层，但在这个阶段，我更看重熟悉度，而不是挤出每一点可能的优化。
我也怀疑这比五年前更为重要。AI 辅助把问题从“这值得构建吗？”改成了“这是不是该构建的东西？”WordPress 一直是摩擦点。改变的是替换它的成本。一旦成本降到足够低，问题就不再是你是否负担得起去改变它，而是你是否能够为不去做它辩护。