在上一篇解决了本地工作流的物理隔离后，系统依然只是一个运行在 localhost 的局域网程序。本篇日志复盘的是如何以极低的成本，打通一条从本地 Markdown 文本到全球边缘节点的自动化分发流水线。
作为一个门外汉，我不想去折腾购买云服务器、配置 Nginx 反向代理或者手动维护 SSL 证书。系统的最高境界是“低耦合、高自动化”。因此，我选择了 GitHub 托管源码，配合 Cloudflare Pages 进行持续集成与部署（CI/CD）。
1. 消除人工干预：构建 CI/CD 流水线
通过将 Cloudflare Pages 与 GitHub 仓库绑定，系统建立了一个自动化的触发机制：只要我在本地 Obsidian 写完笔记，执行 git push，云端就会自动拉取最新代码并触发构建。
这套逻辑看似完美，但在第一次部署时，系统直接抛出了构建失败的报错。
排查日志后发现，这是典型的“本地与云端环境不一致”问题。我本地使用的是 Hugo Extended（扩展版）引擎，而 Cloudflare Pages 默认分配的容器中，Hugo 版本往往非常老旧，无法解析现代前端主题的 CSS 管道。
解决这种跨环境部署问题的标准工程做法，是强制锁定环境变量。
在 Cloudflare 的项目设置中，我注入了两个关键配置：
-
环境变量：设定
HUGO_VERSION = 0.157.0，强制云端容器拉取与我本地完全一致的编译引擎。 -
构建指令：摒弃默认的
hugo命令，改写为hugo --gc --minify。-
--gc(Garbage Collection)：构建前清理无用缓存，防止云端生成冗余数据。 -
--minify：压缩 HTML、CSS 和 JS 的体积，从工程角度节省传输带宽。
-
配置完成后，部署流水线彻底跑通。以后的日常更新被极度压缩为：本地修改文本 -> git push -> 云端在一分钟内自动完成编译并全球分发。没有任何多余的人工介入。
2. 系统命名与采购：不到 20 元的接入成本
虽然流水线通了，但 Cloudflare 默认分配的 *.pages.dev 域名在国内网络环境下存在连接不稳定的问题（易受 DNS 污染或 SNI 阻断）。为了保证系统的可用性，配置一个独立的顶级域名是必选项。
在域名的选择上，灵感源于《Sunset Boulevard》里女主角 Norma 的落幕，形成了一个无法逃脱的命运闭环（Loop）。奈何 sunsetloop.com 无法属于我，故最终敲定了 vesperloop.com。这个命名结合了"Vesper"（晚祷/黄昏）自带自然、大气和时间流转的美学，而 “Loop”（闭环）简直就是控制工程的灵魂（Feedback Loop 闭环控制系统）。
或许每个人的一生，都有一个属于自身的、无法逃脱的“宿命闭环”。
我没有选择国内需要繁琐实名认证的传统大厂，而是转向了 Namecheap 旗下的新锐注册商 Spaceship。在结账时，通过 Google 检索的第三方折扣码 COMPROS，我将 8.88 美元的首年原价压低到了 2.90 美元（约合人民币 20 元不到）。同时，Spaceship 免费提供了 ICANN 强制要求的 WHOIS 隐私保护，规避了个人信息泄露的风险。
3. DNS 主权移交：完成闭环
拿到域名后，最后一步是完成系统网络链路的对接——即将域名的 DNS 解析权彻底移交给 Cloudflare。
我登录 Spaceship 的后台管理面板，将默认的 Nameservers 修改为 Cloudflare 分配给我的专属边缘节点（例如 julian.ns.cloudflare.com 和 uma.ns.cloudflare.com）。
这步操作意味着，当任何访问请求触达 vesperloop.com 时，路由调度将完全由 Cloudflare 的全球网络接管，不仅省去了手动配置 A 记录或 CNAME 的麻烦，还自带了免费的 HTTPS 加密。
在等待全球 DNS 路由表刷新生效后，基础设施的建设正式宣告收官。
在这个阶段，底层的数据管线已经彻底打通。接下来的工程重心，将转向前端表现层——在下一篇 Log 03 中，我将复盘如何处理前端主题（PaperMod）强制自带的排版冲突，以及如何用内联 CSS 夺回页面的视觉控制权。
Comments & Reactions