CloudFlare Worker Cache API无法存储Fetch返回结果问题求助

代码层面修正 #

1. 替换Cache-Control的append操作为set操作
   原代码使用append会保留源站返回的Cache-Control响应头，如果源站返回no-store/no-cache/private等限制缓存的标识，追加的s-maxage=10不会生效，需要先清空原有配置再显式设置允许公共缓存：

// 先删除原有Cache-Control避免冲突
response.headers.delete('Cache-Control')
response.headers.set('Cache-Control', 'public, s-maxage=10')

2. 显式指定缓存匹配规则
   默认cache.match会严格匹配请求方法、请求头中Vary指定的字段，还有请求头中的缓存控制指令，如果需要忽略部分规则可以传入配置参数：

// 示例：忽略请求方法、忽略请求中的no-cache指令
let response = await cache.match(cacheKey, {
  ignoreMethod: true,
  ignoreVary: true,
  ignoreSearch: false // 如果需要忽略URL参数可以设为true
})

3. 增加缓存命中标识方便调试
   给响应添加自定义头，直接通过浏览器开发者工具就能判断缓存是否命中，无需查看日志：

let response = await cache.match(cacheKey)
const cacheStatus = response ? 'HIT' : 'MISS'
if (!response) {
  // 原有回源逻辑
}
// 最后返回前加头
response.headers.set('X-Worker-Cache', cacheStatus)
return response

环境/操作层面排查 #

• 不要用预览模式测试缓存：Worker预览环境的Cache API是模拟实现，不会真实写入和读取缓存，必须将Worker部署到生产环境，通过绑定的自定义域名访问测试。
• 排除请求端的缓存跳过逻辑：测试时不要开启浏览器开发者工具的「禁用缓存」选项，使用curl测试时不要加-H 'Cache-Control: no-cache'类的头，这类请求会直接跳过Cache API回源。
• 注意边缘节点缓存分布特性：Cloudflare的Cache API存储是边缘节点级别的，不同区域的边缘节点缓存不互通。测试时同一地址连续请求3-5次，等请求落到同一节点即可观测到命中。
• 排除源站响应限制：如果源站响应状态码不是200/206，或者响应带Authorization相关标识，Cache API会默认不存储这类响应，如需缓存非200响应可以显式添加Edge-Control: cache-maxage=10头覆盖规则。

内容的提问来源于stack exchange，提问作者Cheyne