都忘记是啥时候了，应该是在博客盛行的尾声，有了自己第一个博客。用了 Blogspot、WordPress、博客园等主流专业博客平台，后面看到一些新奇的平台感觉有个性，就转向 Bitcron(Farbox) 这类小众博客服务商，付费使用约 7 年后，他们说要停运。就想着挺喜欢写小东西的，就自己维护，开启了博客搭建的探索之路。

一、Bitcron 博客服务商

核心特性

支持 Markdown 格式写作，内容可自动发布到 Bitcron 关联网站，且允许自定义域名。

完整发布链路

  1. 本地完成 Markdown 内容撰写；
  2. 通过 Dropbox 网盘自动同步至 Bitcron 后台；
  3. 选择 Bitcron 提供的多种主题；
  4. 1 分钟内自动渲染生成博客页面。

优势

  • 主题设计精美，开箱即用，风格小众且适配性好，经简单调整可满足多数使用场景，支持图片主题、幻灯片等类型，具备自定义能力；
  • 发布方式多样，包含本地 Markdown 同步 Dropbox、命令行同步、邮件发布、在线 WeEditor 发布、微信发布、WebDav 同步发布等；
  • 网站访问速度和稳定性较好，采用多服务器同步部署，缓解国内外访问不稳定问题，基础配置及服务与主流博客平台基本一致；
  • 针对小众用户需求，提供加密、付费等特色功能。

不足

  • 主题自定义配置操作繁琐，无实时预览功能，需通过 Dropbox 同步后刷新页面确认效果，调整效率较低；
  • 围绕 Markdown 构建全链路博客服务，若定位小众产品，团队维护压力较大，用户基数有限导致收益不足，存在成本与收益的平衡难题；
  • 配套开发的全功能 Markdown 编辑器 MarkEditor，支持发布到 Bitcron 及同步 Evernote 等功能，但后期维护不足。推测因采用 QT 技术开发调试性价比低，且团队后续推出另一款收费编辑器，分散了精力，导致该工具迭代停滞。

小思

由于未参与平台运营决策，无法对维护团队的选择做绝对评判。后续了解到该团队转向课程变现业务，对博客服务的投入相应减少。从技术架构来看，该平台的持续维护成本较高，但对用户而言，是一次可行的使用尝试。

二、Serverless + Hexo 博客

搭建背景

早年曾尝试 Jekyll + Github 的博客方案，因国内访问受限放弃，但认可 “仅维护 Markdown 文章” 的静态生成模式。恰逢 Serverless 技术兴起，且本人熟悉相关技术栈，遂启动该方案搭建。

核心逻辑

从语雀拉取内容并转换为 Markdown 格式，通过自主开发的 Serverless Hexo 博客生成器处理后，生成 HTML 等静态文件，最终发布到 OSS（对象存储服务）。

优势

  • 创作便捷性高，语雀编辑体验良好，排版规范，支持画图功能，可在手机、电脑、微信等多端编辑发布文档；
  • 服务成本较低，OSS 与 Serverless 服务计费灵活，支持本地调试主题，修改后即时生效；
  • 基于成熟的 Hexo 框架，可复用市面各类主题，支持简单微调适配需求。

不足

  • Hexo 框架魔改调试难度大，其原生为本地生成架构，适配 Serverless 时需开发虚拟文件系统封装层。部分 Hexo 插件未采用框架自带文件层，需修改全局变量、核心代码及插件逻辑，导致维护成本增加；
  • 线上调试困难，Serverless 服务的线上问题在本地环境难以复现，后期排查故障耗时较长；
  • 服务稳定性不足，语雀接口、OSS 发布均存在限流限制，且响应时长不稳定，发布后需手动验证博客内容是否正常显示。

小思

该方案以自用为核心，初期围绕 Serverless 生态进行适配改造。后期因维护成本高、精力有限，博客更新停滞，项目搁置 3 年。

三、Serverless + Hexo 博客迭代版

针对上一版方案维护成本高的问题，核心原因在于架构复杂，但仍倾向于 Serverless 的技术特性，花费两个周末的部分时间进行重构，计划将 Hexo 生成代码封装为 Library 简化架构，然后按需调用。但重构后仍还有比较多问题，最终意识到不应以技术为核心导向进行方案设计，需优先匹配实际需求。

四、Hexo 博客 + Github Action + OSS

搭建思路

复盘前期方案，明确核心优化目标是降低维护成本、解决线上调试难题。结合 Hexo 原生适配本地运行的特性，引入 Github Action 构建新架构。

优势

  • 触发机制简洁，通过 Serverless 编写少量代码实现接口，用于触发 Github Action 运行，比较适合 Serverless 的轻量特性；
  • 调试便捷，文章生成全流程日志可在 Github Action 后台查看，便于定位问题；
  • 支持内容缓存，Github Action 可缓存上次同步内容，提升生成速度，减少限流情况；
  • 主题调试一致性高，本地与线上环境差异小，修改后验证效率高。

不足

生成速度仍有优化空间，最快需 30 秒左右完成生成流程，该速度在静态站点生成（SSG）场景下基本可满足使用需求。

五、小结

当前采用的 Hexo + Github Action + OSS 方案，与最初的 Bitcron 方案相比，虽未实现一体化整合的高效性，但通过整合各平台优势，成为小众场景下维护成本较低的可行方案。实际使用中，当朋友反馈博客主题或配置问题时，通过 Cursor Remote Agent 在手机端完成 PR 提交、合并及重新发布操作还是非常适应当前的时代发展🤣。其实很好地反应了根据具体的需求进行定制化的设计是很重要的。