本来只是想放一条链接
最初的任务非常小：为了推进联盟平台的网站审核，在一篇实际文章里放入一条外置 HDD 的联盟链接。
页面需要有正常内容，在商业链接之前清楚说明“通过该链接购买时，运营者可能获得报酬”，并确保链接可以正常跳转。联盟链接已经生成，文章也已经提交到 GitHub。
然后真正的问题出现了。
代码存在于 GitHub，并不等于网页已经在互联网上发布。
平时使用的 GitHub Actions 路径暂时不可用。随后又考虑过用 Cloudflare Worker 只拦截这一条 URL 进行临时发布，但在当前运行条件下，Worker 路径同样不可用。
于是，一条联盟链接突然变成了关于 CI、Worker、Pages、Git integration 和 Direct Upload 的部署会议。
“联盟营销版圣家堂二号楼”差点就此开工。
好消息是，只要先把部署机制分开，问题就会简单很多。
1. 为什么必须先有真实可访问的页面
Sovrn Commerce 面向内容网站和博客的入门指南说明：站点需要先安装或实现 Commerce 联盟链接，并产生点击，然后才进入审核流程。[3]
所以并不是单纯的“先批准，再放链接”。审核方需要能够看到一个真实的实现示例。
Sovrn 还说明，在包含联盟链接的页面上，应清楚告知读者存在可能的报酬关系，而且 disclosure 应出现在联盟链接或推广内容之前。[4]
一个最基本的审核页面并不复杂：
- 申请的网站上确实有文章；
- 文章中存在联盟链接；
- 链接之前有明确的 disclosure；
- 公开 URL 可以正常访问；
- 实现后可以产生少量确认点击。
这里最重要的一点是：repository 中的文件，不等于公开网页。
2. GitHub Actions 不可用，并不代表 Cloudflare Pages 也不可用
GitHub Actions 是 GitHub 提供的 CI/CD 系统，可以执行 build、test 和 deploy。
Cloudflare Pages 还有自己独立的 Git integration。Pages 可以直接连接 GitHub 或 GitLab；当连接的 repository 收到 push 后，Cloudflare 可以自己执行 build 和 deploy。[1]
流程可以是：
push 到 GitHub → Cloudflare Pages 检测 commit → Cloudflare build → Cloudflare deploy
这条链路并不要求 GitHub Actions workflow 存在。
因此，“GitHub Actions 不能用”和“GitHub 无法自动发布到 Cloudflare”并不是同一件事。
如果把 GitHub Actions 看成仓库内部的传送带，那么 Cloudflare Git integration 更像是物流公司直接到仓库取货。
传送带停了，不代表取货车辆也停了。
3. 第一步不是找捷径，而是确认现有 Pages 项目属于哪一种
Cloudflare Pages 主要有两种部署模型。
| 模型 | 触发方式 | build/deploy 在哪里完成 | 适合场景 |
|---|---|---|---|
| Git integration | push 到 GitHub/GitLab | Cloudflare | 以 repository 为准并自动发布 |
| Direct Upload | 预先生成的 build 输出 | Wrangler 或控制台 | 在本地或其他 CI 中 build 后直接上传 |
Cloudflare 官方文档指出：用 Git integration 创建的 Pages 项目，不能直接改成普通 Direct Upload 项目。已经连接 Git 的项目仍可通过 Wrangler 手动部署，但不能对这个既有 Git 集成项目使用控制台 drag-and-drop。[1][2]
反过来也一样重要：以 Direct Upload 创建的项目，之后不能在同一个项目中直接添加 Git integration。若要改成自动 Git 部署，需要建立新的 Pages 项目。[2]
因此第一个问题不应该是“我要用哪个绕路技巧？”
而应该是：“现有 Pages 项目到底是 Git integration，还是 Direct Upload？”
确认这一点，部署迷宫会立刻少一半。
4. 如果是 Git integration，就不需要为了发布而恢复 GitHub Actions
如果 GitHub repository 已经正确连接到 Cloudflare Pages，最短路径不是 Worker，也不是再找一个 CI 服务。
应该在 Pages 项目中确认：
- 连接的是正确的 GitHub repository；
- production branch 是真正用于发布的 branch；
- 该 branch 的自动 build 没有被关闭；
- build command 和 output directory 与当前项目一致；
- push 后，Pages 的 Deployments 页面出现新的 deployment；
pages.dev地址已经显示新内容；- custom domain 也显示相同的新内容。
Cloudflare Git integration 本来就是为了根据连接 repository 的 commit 执行 build 与 deploy。[1]
只要这条路径还活着，GitHub Actions 的暂时限制并不意味着必须重建整套部署架构。
在挖新的紧急隧道之前，先看看正门是不是本来就开着。
5. 如果是 Direct Upload，应该部署完整 build 输出，而不是手工塞一个页面
Direct Upload 的逻辑是：先在其他地方完成 build，再把生成的 assets 上传到 Pages。Cloudflare 对 Direct Upload 项目支持 Wrangler 和控制台 drag-and-drop。[2]
很容易产生一个诱人的想法：
“我只改了一篇文章，能不能只上传一个 HTML？”
对于静态站点生成器，这通常不是好主意。
部署单位不是“刚修改的那一个 source file”，而是整个 build output。build 过程中可能同时生成 routing、CSS、JavaScript、搜索索引、metadata、assets 和其他页面。
更稳妥的流程是：
取得最新 source → 执行项目 build → 检查 output directory → 部署完整输出 → 验证真实 URL
Node 静态项目可能使用类似 pnpm build 的项目命令，并生成 dist 一类目录。
重点是不要让生产环境变成一个和 repository 脱离的“手工平行宇宙”。
6. Worker 不能用，就把它从设计图上删掉
用 Worker route 临时处理一个紧急 URL，技术上当然可以成立。
但如果当前环境无法使用 Worker，那么继续把 Worker 当作主要后备方案，只会增加复杂度。
决策可以直接缩减为：
- GitHub Actions 不可用；
- Worker 路径不可用；
- 那么只在现有 Pages Git integration 与合法 Direct Upload 路径之间选择。
与其设计十个紧急出口，不如先找到一个真的能打开的门。
不要为了发布一条联盟链接，再造第二套部署平台。
7. “已发布”必须由真实网页证明，而不是 commit SHA
写完代码、提交 commit、build 成功、出现 deployment，都只是中间里程碑。
最终读者看到的是公开 URL。
对于联盟审核页面，至少应该验证：
- 在干净浏览器会话中可以打开公开 URL；
- 最新正文已经显示；
- disclosure 位于联盟链接之前；
- 商品链接跳转到预期目标；
- 移动端显示正常；
- 如审核流程需要，产生少量确认点击；
- 在 Sovrn 后台确认点击或审核状态。
Sovrn 的内容／博客入门流程明确包含“实现链接 → 产生点击 → 审核”。[3]
因此，审核真正的起点，是审核方可以访问并看到真实实现的网页。
8. 规模扩大后，不要把联盟 URL 永久写死在正文里
一条链接可以手工处理。
但如果文章达到数百或数千篇，每次都人工决定“要不要商业化、放哪里、选什么商品、面向哪个市场”，内容工厂旁边就会长出第二座广告工厂。
更稳定的做法是把编辑正文和商业 metadata 分开。
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
之后的流程可以变成：
article → monetization gate → product candidates → affiliate link generation → renderer insertion → performance measurement
正文作为长期资产保留；商品 URL、库存、merchant 和国家 routing 则作为可替换部件。
联盟系统最好像接在文章上的商业管道，而不是浇进文章地基里的混凝土。
9. 结论：CI 不可用时，先找到 Cloudflare 真正的入口，再考虑盖新城堡
整个故事从一条 HDD 联盟链接开始。
链接有了，disclosure 有了，source 也进了 GitHub。
但 CI 路径不可用，Worker 绕路也不可用。
如果这时继续叠加新系统，目标就会从“发布一个链接”变成“建设另一套部署平台”。
真正需要的判断很少：
- 如果现有 Pages 是 Git integration，就使用 Cloudflare 原生 Git build；
- 如果是 Direct Upload，就 build 整个站点并通过受支持的方式部署完整输出；
- Worker 不可用就从决策树删除；
- 不要把 Git commit 当成生产发布；
- 在真实公开 URL 上验证 disclosure、链接、显示和点击。
最危险的架构不是选择太少。
而是那些已经不能用的选择，永远没有从设计图上删除。
