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（代码部署）模式。 ...