边缘计算数据缓存是降低源站压力、提升用户响应速度的核心手段。但在实际配置中，很多人会遇到缓存命中率低、内容更新不及时、缓存风暴等问题。本文直接从这些痛点切入，结合 Cloudflare 官方文档，讲解如何制定有效的缓存策略。
先判断：你的业务适合缓存吗？
在动手配置前，先明确哪些内容值得缓存。Cloudflare 缓存官方文档指出，缓存适合存储频繁访问的内容，例如图片、视频或网页。但动态数据（如用户购物车）或个性化内容通常不适合缓存。你可以通过分析请求日志，找出重复请求占比高的资源。如果 80% 的流量集中在 20% 的静态资源上，缓存收益会非常明显。
默认缓存行为：别急着自定义
Cloudflare 默认会缓存一部分静态文件扩展名（如 .jpg、.css、.js），但不会缓存 HTML 页面（除非你配置）。了解默认行为很重要，因为它决定了哪些请求会命中缓存，哪些会回源。你可以通过响应头 cf-cache-status 查看缓存状态：HIT 表示命中，MISS 表示未命中，BYPASS 表示绕过。观察日志，找出未命中的资源，再决定是否调整规则。
用 Cache Rules 精确控制缓存行为
默认规则无法满足所有场景，Cloudflare 提供了 Cache Rules，允许你根据 URL、请求头、设备类型等条件指定哪些资源需要缓存以及缓存多久。例如，你可以对 /static/* 下的资源设置缓存 30 天，对 API 响应设置缓存 60 秒。关键操作步骤如下：
- 登录 Cloudflare 控制台，进入 Caching 选项卡，选择 Cache Rules。
- 创建规则，设置匹配条件（如 Hostname、Path 或 Query String）。
- 指定缓存持续时间（TTL），并选择是否忽略查询字符串（若资源与查询参数无关，可忽略以提升命中率）。
- 测试规则：使用 curl 或浏览器开发者工具检查响应头，确认缓存生效。
注意：TTL 过长会导致内容更新延迟，过短则增加回源请求。建议根据内容更新频率设置，例如图片可以设置 30 天，而促销页面可能只需 60 秒。
分层缓存：Tiered Cache 减少回源压力
Cloudflare 的 Tiered Cache 功能可以在多个节点间分层缓存，让边缘节点从上层节点（而非源服务器）获取内容，从而降低源站流量。官方文档强调，这能优化内容交付并减少源站流量。启用方法：在 Caching 设置中开启 Tiered Cache，并选择拓扑结构（如 Smart Tiered Cache）。实际效果取决于你的流量分布，如果用户集中在少数区域，收益可能不明显。
持久化存储：Workers KV 与 Cache API
对于动态生成但可复用的数据（如用户配置、API 响应），Cloudflare Workers 提供了 KV 存储（Workers KV），它是一种低延迟的键值存储，支持边缘缓存读取。文档指出，KV 适合“fast, edge-cached reads”。你可以用 Workers 脚本将数据库查询结果写入 KV，并设置 TTL，后续请求直接从 KV 读取，避免源站计算。但要注意：KV 是最终一致性，写入后可能延迟生效，不适合需要强一致性的数据。
示例代码：
async function handleRequest(request) {
const cacheKey = new Request(request.url, request);
const cache = caches.default;
let response = await cache.match(cacheKey);
if (!response) {
response = await fetch(request);
const headers = new Headers(response.headers);
headers.set('Cache-Control', 'public, max-age=60');
response = new Response(response.body, { headers });
await cache.put(cacheKey, response.clone());
}
return response;
}这段代码先查缓存，未命中则回源，并将结果写入缓存。注意，caches.default 是 Cloudflare 的缓存 API，与 Cache Rules 不同，它运行在 Worker 内，适合更细粒度的控制。
缓存清除：避免陈旧内容
当源站内容更新时，你需要主动清除缓存。Cloudflare 支持即时清除特定文件或全部缓存。官方文档提到，你可以 purge specific files or all at once。操作方式：在 Caching 选项卡的 Purge 中，输入 URL 或使用 API。注意，清除操作会立刻使缓存失效，导致大量回源请求，建议在流量低峰期执行，或使用条件清除（如按 Cache-Tag 清除）。
常见误区与失败条件
- 误设 TTL 过长：导致内容更新不及时，用户看到旧版本。解决：根据内容更新频率设置 TTL，或用 Cache-Tag 进行部分更新。
- 忽略查询字符串：如果资源 URL 带有唯一查询参数，而缓存策略忽略了它，可能返回错误内容。解决：在 Cache Rules 中明确处理查询字符串。
- 缓存动态页面：直接缓存 HTML 但未考虑用户状态，导致用户看到他人数据。解决：仅缓存匿名请求，或使用 Worker 进行个性化处理。
- 未监控命中率：不关注缓存命中率，无法评估策略效果。解决：定期查看 Analytics 中的缓存指标，调整规则。
结合无服务器与边缘缓存
如果你的业务使用 GraphQL 等动态 API，可以参考 ZuCDN 上的相关文章：CDN边缘计算上的无服务器GraphQL网关设计原理 和 边缘节点新玩法：语义识别GraphQL POST请求并智能缓存，它们提供了在边缘层处理 POST 请求缓存的思路。此外，边缘动态渲染：CloudFront+Lambda@Edge对比评测 可帮助你对比不同边缘方案的取舍。
总结：构建你的缓存策略
制定缓存策略时，先分析内容类型和访问模式，再配置 Cache Rules 和 Tiered Cache，必要时用 Workers KV 处理动态数据，并建立清除机制。监控命中率，持续优化。记住，缓存不是银弹，需要和源站架构、业务逻辑配合。根据 Cloudflare 文档，这些实践能显著提升性能，但具体效果取决于你的场景，建议小流量测试后再全面推广。
参考资料
延伸阅读