文章归档

静态博客看起来是最轻的工程项目：Markdown 写内容，主题渲染页面，执行一次构建就能发布。但只要它依赖 Node.js、npm、主题包和渲染插件，它就不是一堆“永远可用”的文本，而是一条会随运行时变化而漂移的构建链。

很多博客维护问题并不来自文章本身，而来自环境变化：本机 Node 版本升级后主题样式编译失败，CI 镜像换代后依赖重新解析，旧插件在新运行时里触发弃用行为。越是低频维护的个人站点，越容易在下一次发布时才发现构建已经不稳定。

Hexo 适合做个人技术博客，GitHub Pages 适合托管静态站点。两者组合起来之后，日常维护可以很轻：本地写 Markdown，Hexo 生成静态文件，再把生成结果发布到 GitHub Pages。

这篇文章记录一套从零配置流程：如何创建 GitHub Pages 仓库、如何配置 Hexo、如何发布站点、如何绑定自定义域名，以及可以尝试哪些免费的域名或子域名服务。

Hexo 博客通常会涉及两个不同概念：源码仓库和发布仓库。源码仓库存放 Markdown、主题配置、脚本和静态资源；发布仓库存放 hexo generate 之后生成的 HTML、CSS、JS 和图片。

如果这两个仓库的边界不清楚，后续维护很容易混乱：源码没有保存，发布内容能访问但无法复现；或者把生成文件提交到源码仓库，导致 diff 变得很吵；再或者把源码误推到 GitHub Pages 仓库，影响线上站点结构。

每天写技术博客最容易卡住的地方，往往不是不会写，而是流程太碎：选题、确认仓库格式、创建 Markdown、补 front matter、检查构建、再执行部署。每一步都不复杂，但合在一起就会变成一种阻力。

Codex CLI 适合处理这类重复性内容工作。它可以在当前仓库里阅读已有文章，理解 Hexo 的目录结构和 front matter 约定，然后按同样的风格新增文章。再配合一个小脚本，就可以把“生成今日文章”和“部署到 GitHub Pages”合成一个稳定入口。