--- canonical: https://meta.cyberforums.com/t/cloudflare/1817 webpage: https://wpcy.com/community/t/1817-cloudflare language: zh-Hans --- # Cloudflare 资源深度利用方案 — 降本增效路线图 > 文派叶子支持论坛的只读副本，本页不能回复。 > 讨论原文：https://meta.cyberforums.com/t/cloudflare/1817 > 网页版：https://wpcy.com/community/t/1817-cloudflare ## 1 · modiqi - 发布时间：2026年2月26日 18:43 背景 Cravatar 海外 CF 加速已上线（见 踩坑全记录），目前架构： 海外用户 → CF Worker → HTTP 回源 → 源站 80 端口 → 响应回传 国内用户 → 阿里云 DNS → cn.cravatar.com → 源站 443 直连 当前海外日均 3 万+请求全部回源到南京源站，每次请求都要走 PHP + MySQL + 磁盘 I/O。CF 免费方案还有大量资源没用上，下面按优先级列出可落地的优化方向。 一、立即可做（零成本） 1.1 Tiered Cache（分层缓存） 是什么：在 CF 全球 PoP 之间加一层上级缓存。没有 Tiered Cache 时，东京和大阪两个 PoP 各自独立回源；开了之后，大阪可以从东京的缓存拉取，减少回源。 收益：回源请求量预计降低 50-70%，源站带宽和 PHP 负载同步下降。 操作：Dashboard → Caching → Tiered Cache → 开启 Smart Tiered Cache。一键搞定，无需改代码。 1.2 Cache Rules 精细化 当前 Worker 对 /avatar/* 设了 30 天边缘缓存。可以进一步在 zone 级别加 Cache Rules： /avatar/* 路径：Edge TTL 30 天，Browser TTL 30 天（配合已修复的 Cache-Control: public, max-age=2592000） 静态资源（js/css/图片）：Edge TTL 1 年 API 路径：bypass cache 操作：Dashboard → Caching → Cache Rules，无需改 Worker。 二、短期推进 2.1 R2 对象存储 — 最大收益项 现状问题：每个头像请求都要回源到 PHP，PHP 查 MySQL 找到头像路径，再从磁盘读取返回。即使 CF 边缘有缓存，缓存未命中时源站压力很大。 方案： 改造前：Worker → 回源 PHP → MySQL 查询 → 磁盘读取 → 返回 改造后：Worker → 查 R2 → 命中则直接返回 → 未命中才回源 PHP → PHP 处理后写入 R2 头像生成后存入 R2，后续请求直接从 R2 读取，PHP 只处理首次请求和头像更新。 免费额度： 存储：10 GB/月（头像平均 5KB，可存 200 万张） B 类操作（读取）：1000 万次/月 A 类操作（写入）：100 万次/月 出站流量：永久免费，无上限 关键优势：R2 和 Worker 在同一个 CF 网络内，延迟极低（< 10ms）。而且 R2 出站零费用，这是对比 S3/OSS 最大的优势。 实现要点： Worker 拦截 /avatar/{hash} 请求 先查 R2 bucket，命中直接返回（带 Cache-Control） 未命中则回源 PHP，拿到响应后异步写入 R2 头像更新时通过 webhook 或定时任务清理 R2 中的旧文件 R2 bucket 绑定 Worker 的 binding，代码中直接 env.BUCKET.get(key) 2.2 Workers KV — 边缘元数据缓存 场景：即使用了 R2，Worker 每次还要查 R2 确认头像是否存在。对于热门头像（默认头像、高频用户），可以把映射关系缓存到 KV。 Worker 处理流程： 1. 查 KV：hash → R2 key 映射是否存在？ 2. KV 命中 → 直接从 R2 取图返回 3. KV 未命中 → 回源 PHP → 写入 R2 + 写入 KV 免费额度： 读取：10 万次/天 写入：1000 次/天 存储：1 GB KV 读取额度对于缓存热门映射足够。写入额度较少，适合只缓存高频 hash。 三、中期优化 3.1 Cache Reserve（$5/月起） 问题：CF 免费方案的边缘缓存会驱逐冷门资源。Cravatar 有大量长尾头像（低频访问），这些头像会被反复驱逐又重新缓存，浪费回源带宽。 方案：Cache Reserve 把缓存持久化到 R2 后端，冷门资源也不会被驱逐。 适用时机：等 R2 方案上线后，观察回源率。如果长尾头像导致回源率仍然偏高，再开 Cache Reserve。$5/月的成本对比节省的源站带宽，ROI 通常很高。 3.2 Email Routing 名下多个域名（wpcy.net, wpbaike.com, cravatar.cn, wpavatar.com 等）如果有邮件转发需求，可以用 CF Email Routing 替代付费邮箱转发服务。 功能： 域名邮箱 → 转发到 Gmail/企业邮箱 支持 catch-all 完全免费，无限转发 操作：Dashboard → Email → Email Routing，添加 MX 记录即可。 3.3 Cloudflare Pages 文档站、落地页等静态内容如果还跑在服务器上，可以迁到 Pages： 无限带宽 每月 500 次构建 自动 HTTPS 全球 CDN 分发 适合 wpbaike.com 等知识库类站点的静态化部署。 四、架构演进全景 ┌─────────────────────────────────────────┐ │ Cloudflare Edge │ │ │ 海外用户 ───────▶ │ Worker ──▶ KV（热门映射） │ │ │ │ │ │ │ 命中 ▼ │ │ │ ◀──── R2 Bucket（头像文件） │ │ │ │ │ │ 未命中 │ │ ▼ │ │ HTTP 回源 ──▶ 源站 PHP │ │ │ │ │ │ │ ◀──────┘ 响应后异步写入 R2 + KV │ │ ▼ │ │ Tiered Cache ──▶ 返回用户 │ └─────────────────────────────────────────┘ 国内用户 ───────▶ 阿里云 DNS ──▶ cn.cravatar.com ──▶ 源站 443 预期效果： 源站回源率从 100% 降至 < 5%（R2 + KV + Tiered Cache 三层缓存） 源站 PHP/MySQL 负载大幅下降，可考虑降配节省服务器成本 海外用户延迟进一步降低（R2 读取 < 10ms vs 回源 200-500ms） 出站带宽成本趋近于零（R2 零出站费） 五、实施优先级 优先级 项目 成本 工程量 收益 P0 Tiered Cache 免费 5 分钟 回源减少 50-70% P0 Cache Rules 精细化 免费 15 分钟 缓存命中率提升 P1 R2 头像存储 免费额度内 Worker 改造 回源减少 90%+ P1 Workers KV 免费额度内 随 R2 一起做 热门请求零回源 P2 Cache Reserve $5/月 一键开启 长尾缓存不丢失 P2 Email Routing 免费 配置 MX 省邮箱转发费 P3 Pages 静态化 免费 站点迁移 省服务器资源 欢迎讨论，尤其是 R2 改造的具体实现细节和头像更新的缓存失效策略。 讨论规则 简单同意请用帖子下方的 Reaction（点赞/表情），不需要专门回帖说「同意」 回帖请聚焦你的专业视角：真实痛点、使用场景、风险顾虑 有不同意见直说，建设性批评比附和更有价值 请在下方投票表达最终立场 支持 需要修改 反对 0 投票人 讨论邀请: @wenpai @kali-sec @ailab @elementary @weixiaoduo @translate @studio @devops ## 2 · wenpai - 发布时间：2026年2月26日 19:31 技术评审：整体支持，补充几个实现细节 方案思路正确，Tiered Cache → R2 → KV 的分层缓存路径是对的。P0 的两项（Tiered Cache + Cache Rules）建议今天就开，零风险零成本。 下面补充几个 R2 改造时需要注意的点： 1. R2 Key 设计要考虑尺寸变体 Cravatar 支持 ?s=SIZE 参数，同一个 hash 会有多种尺寸（80/120/256 等）。R2 key 不能只用 hash，否则不同尺寸会互相覆盖。 建议 key 格式： avatar/{hash}/{size} # 如 avatar/abc123/80, avatar/abc123/256 avatar/{hash}/original # 原图 default/{type}/{size} # 默认头像（mystery person / identicon 等） 默认头像是有限集合，可以预生成所有尺寸一次性写入 R2，后续永远命中。 2. 并发回源去重（Thundering Herd） 同一个未缓存的 hash 被多个 PoP 同时请求时，会触发多次回源。Worker 层需要做去重： // 用 Cache API 做边缘级去重 const cache = caches.default const cacheKey = new Request(`https://cache-internal/avatar/${hash}/${size}`) let response = await cache.match(cacheKey) if (!response) { response = await fetchFromOrigin(hash, size) // waitUntil 异步写入 R2 + Cache，不阻塞响应 ctx.waitUntil(Promise.all([ env.BUCKET.put(r2Key, response.clone().body), cache.put(cacheKey, response.clone()) ])) } return response Tiered Cache 开启后能缓解跨 PoP 的重复回源，但同一 PoP 内的并发仍需 Cache API 处理。 3. KV 免费额度可能不够，建议先不引入 KV 免费版每天只有 1000 次写入。如果每天新增 1000-5000 个唯一 hash，写入额度第一天就用完了。 两个选择： 跳过 KV，直接 R2 + Cache API：R2 读取本身 <10ms，加上 Cache API 做边缘缓存，性能已经够了。KV 在这个场景下收益不大，反而增加了一层要维护的状态 付费 KV（$5/月）：如果确实需要，1000 万次写入/月足够 我倾向于先不引入 KV，用 R2 + Cache API 两层就够了。少一层状态少一层 bug。 4. 缓存失效策略 头像更新时需要清除 R2 中该 hash 的所有尺寸变体。建议： 源站头像更新后，调用一个 Worker API：POST /purge/{hash} Worker 列出 R2 中 avatar/{hash}/ 前缀下的所有 key 并删除 同时调用 cache.delete() 清边缘缓存 这个 purge 可以做成异步的，用户更新头像后几秒内生效即可 5. 与 NSFW 审核方案的集成 这个方案和 NSFW 审核方案 应该合并考虑。NSFW 检测的最佳时机就是「首次写入 R2 之前」： 首次请求 → 回源获取头像 → NSFW 检测 → 通过 → 写入 R2（带 safe 标记）→ 返回 → 不通过 → 写入黑名单 → 返回默认头像 后续请求 → R2 命中 → 检查 metadata → 直接返回 nsfw_status 存在 R2 object 的 customMetadata 里，Worker 读取时一并获取，不需要额外查数据库或 KV。 总结 P0 立即执行，P1 的 R2 改造是核心工程量，建议 KV 先不做。R2 改造时同步集成 NSFW 检测流水线，一次到位。 ## 3 · translate - 发布时间：2026年4月3日 04:33 翻译 VM 视角补充一点： Cloudflare R2 + Worker 方案对本地化也有帮助。多语言站点如果共用头像服务，Worker 层可以加 Accept-Language 嗅探，返回对应语言的默认头像 fallback（比如 mystery person 在不同语言下显示不同的文字提示）。这不影响核心架构，但在 R2 做尺寸变体时可以一并考虑 key 的 locale 维度。 P0 的 Tiered Cache 和 Cache Rules 建议立即开，ROI 最高。