缘起：不满足于“拿来主义”
昨天，我初步完成了一个 Hexo 博客的搭建，并成功部署到了 GitHub Pages。当时应用了非常漂亮的 Fluid 主题，并且通过配置开启了对 $\LaTeX$ 复杂公式的渲染支持。
公式测试：
$$e^{i\pi} + 1 = 0$$
看到上面这个优美的公式能正常显示，就知道 MathJax/KaTeX 已经成功 Run 起来了。
然而，之前的搭建过程更像是在一个“成品站”的基础上修修补补。作为一个 CS 人，总觉得如果不从零开始清理一遍底层逻辑（尤其是那些乱糟糟的 Git 索引和子模块记录），心里总是不踏实。于是，我决定：推倒重来，构建一套更稳健、更快速的工作流。
核心进化：双平台并行部署
为了优化国内的访问速度，我不再局限于 GitHub Pages，而是引入了 Cloudflare Pages 进行同步托管。
1. 为什么选择双部署？
- GitHub Pages：老牌稳定，作为主仓库的直接产物。
- Cloudflare Pages：全球 CDN 加速，尤其是国内访问速度提升明显，且支持自动监听 GitHub 提交。
2. 踩坑记录：消失的 landscape 与子模块阴影
在重新搭建的过程中，遇到了最棘手的问题：GitHub Actions 报错找不到主题文件。
- 现象：GitHub 网页上
themes/landscape文件夹带有一个“白色小箭头”，无法点击。 - 原因：
git clone带来的.git文件夹让 Git 误以为它是子模块（Submodule），只传了索引没传内容。 - 方案：强制执行
git rm -r --cached .，彻底大扫除，重写 Git 账本。
现在的自动化工作流
现在，我的发布流程已经进化到了“傻瓜式”级别：
- 本地创作：使用 VS Code 编写 Markdown 源码。
- 一键推送：
git push到 GitHub 的main分支。 - 双重构建：
- GitHub Actions 自动编译并推送到
gh-pages分支展示。 - Cloudflare Pages 实时感应并启动分布式构建。
- GitHub Actions 自动编译并推送到
总结
这次“重装系统”式的搭建过程虽然折腾，但让我彻底理清了 Git 索引、GitHub Actions 自动化部署以及静态网站托管的逻辑。
未来，这里将是我记录技术心得和生活点滴的新起点。Stay hungry, Stay foolish!