文章归档

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

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

分区规划是嵌入式 Linux 产品的底层设计。它决定了系统如何启动、OTA 如何升级、配置是否保留、日志写到哪里、异常断电后能否恢复。分区设计不清楚，后面很多功能都会变成补丁。

嵌入式产品最终要进入生产和现场。开发阶段能跑，不代表适合量产。生产测试、出厂配置、版本追踪和日志导出，是从开发样机走向产品必须补齐的环节。

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

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

一、发布不只是复制文件

很多程序本地能跑，但上线后容易出问题，原因通常不是代码本身，而是发布流程不规范。

一个可靠发布流程要解决：

• 发布哪个版本。
• 发布哪些文件。
• 配置放在哪里。
• 日志怎么看。
• 失败怎么回滚。
• 依赖库是否齐全。
• 启动和停止是否可控。

一、为什么要服务化

一个程序能在终端运行，不代表适合部署。真正部署到 Linux 设备或服务器时，需要解决：

• 开机自动启动。
• 异常退出自动重启。
• 统一查看日志。
• 使用非 root 用户运行。
• 控制启动顺序。
• 优雅停止。

Linux 现代发行版通常使用 systemd 管理服务。