Cloudflare 捉迷藏：我是如何被产品经理玩弄了三小时的

建一个极简的静态博客需要多久？

看完网上的教程，我以为最多只要十分钟。毕竟“Hugo + GitHub + Cloudflare Pages”已经是目前公认最省心、最长久的“养老级”建站配方。我连博客的定位都想好了——一个没有任何社交元素、只有纯粹文字的“安静后花园”。

但现实给我狠狠上了一课：在这个代码甚至都能让 AI 帮着写的时代，打败你的，往往只是一个被产品经理藏起来的按钮。

掉进“伪装者”的陷阱

一切的起步都很顺利。本地安装 Hugo，挑了一个极简的 PaperMod 主题，写好 Markdown 测试页，推送到 GitHub。这部分如丝般顺滑，让我产生了一种“我也是极客”的错觉。

直到我打开 Cloudflare 准备部署上线。

按照教程，我应该找到一个叫“Pages”的入口，连上 Git，然后一键发布。但我眼前的界面只有“Create Application”。我毫不犹豫地点了进去，选了 GitHub 仓库，然后噩梦就开始了。

构建报错：Command failed with exit code 1: npx hugo。 系统提示找不到 hugo 的 npm 包，日志里还混杂着 npx wrangler deploy 这种我根本看不懂的指令。

我翻遍了所有的报错帖，有人说要改环境变量，有人说要查子模块。我改了无数次 hugo.toml 里的 baseURL，在终端里敲烂了 git push，但迎来的始终是一片苍白的空白页。

更绝望的是，教程里说要在“Edit output settings”里把输出目录填成 public，而我的后台设置里，连这个选项的影子都没有，只有一个孤零零的“Root directory”。

我开始严重怀疑自己：这么简单的事情，大家都说点几个按钮就好，为什么我不行？难道我连做个数字废物的资格都没有了吗？

产品经理的“阴谋”

在与 AI 助手进行了长达一小时的极限拉扯，逐行分析了构建日志后，真相终于浮出水面。

根本不是我的代码有问题，而是我进错了门。

Cloudflare 最近为了推行他们宏大的“全家桶”战略，把用来运行复杂代码的 Workers 和用来托管静态页面的 Pages 强行塞进了一个入口。当你兴冲冲地点开“Create Application”时，系统默认把你引导到了更为复杂的 Workers（代码部署）模式。

在这个模式下，它不认识什么 Hugo 预设，也不自动找 public 文件夹，它只会按照处理代码的逻辑一顿瞎跑，最后给你扔一堆报错。

而真正适合普通人、带有一键自动化流水线的 Pages 模式，被折叠、隐藏在了一个需要切换选项卡才能看到的偏僻角落。 [[./../imgs/cloudflare-pages.png]]

如果你不仔细看，根本发现不了那个极其微小的“Connect to Git”按钮。连国外技术社区的大佬都在截图吐槽：“Ah! Sneaky! I did not see that. Is Cloudflare trying to phase out Pages?"（太狡猾了！我根本没看到。Cloudflare 是想把 Pages 淘汰掉吗？）

原来，全世界的极客都在被这套“自作聪明”的 UI 设计折磨。

破局与开园

解决问题的方法简单得令人发指，也更加印证了之前的折腾有多荒谬：

1. 把那个错误的、折磨了我几个小时的 Worker 项目直接删除。

2. 回到起点，点击 Create。强迫自己无视下方巨大的诱导按钮，点击上方那个不起眼的【Pages】选项卡。

3. 终于，那个熟悉的“Connect to Git”出现了。

选好仓库，在 Framework preset 里选上 Hugo。就在那一瞬间，失踪的 Build command 和 Output directory 像变魔术一样自动弹了出来。

点击“Save and Deploy”。 几十秒后，页面上亮起了绿色的 “Success: Your site is deployed”。

点开链接，大白底、黑字的极简博客瞬间加载出来，排版完美，没有任何报错。

看着这个干净的页面，我长长地舒了一口气。三个小时的自我怀疑和愤怒，在这一刻烟消云散。

虽然过程曲折得像是在玩一场极其恶劣的捉迷藏，但好在，我终于拿到了自家后花园的钥匙。这篇碎碎念就作为开园的第一篇文章吧，留给未来的自己，也留给下一个在 Cloudflare 迷路的倒霉蛋：

兄弟，不要怀疑你的代码，去怀疑产品经理。