Cloudflare Workers 兼容性标志解析让 Cache API 请求中的cf缓存设置覆盖 Cache Rules【免费下载链接】cloudflare-docsCloudflare’s documentation项目地址: https://gitcode.com/GitHub_Trending/cl/cloudflare-docs导读本篇文章以 Cloudflare Docs 仓库中的兼容性标志文档 cache-api-request-cf-overrides-cache-rules.md 为核心深入讲解cache_api_request_cf_overrides_cache_rules这个兼容性标志compatibility flag的语义、启用方式、生效前提与实际影响。读完本文你将掌握Workers 的 Cache APIcaches.default.put()/caches.default.match()与 Cache Rules缓存规则之间的优先级关系如何通过cf对象中的cacheEverything、cacheTtl等缓存设置覆盖缓存规则以及在不同 compatibility date 下该行为如何受标志开关的默认状态控制。背景Cache API、cf对象与 Cache Rules在 Cloudflare Workers 中有三套机制会共同影响某个请求/响应是否被缓存、缓存多久Cache API通过caches.default.put()、caches.default.match()等方法在 Worker 内以编程方式读写 Cloudflare 全局网络缓存。它是一套独立的缓存接口与让 Cloudflare 直接缓存 Worker 响应的 Workers Caching 机制互相独立见 Cache API 文档。cf对象在fetch()请求或 Cache API 的request参数上携带cf属性可声明本次请求的缓存意图例如cacheEverything: true、cacheTtl: 86400、cacheTtlByStatus等见 Request 文档中的cf属性。Cache Rules在 Cloudflare 控制台或 API 中配置的缓存规则用于调整哪些内容可被缓存、缓存多久、缓存在哪里等设置见 Cache Rules 文档。当这三者同时作用于同一个请求时谁的设置说了算答案由本文的主角——兼容性标志cache_api_request_cf_overrides_cache_rules——决定。标志定义Cache API 请求中的cf设置覆盖 Cache Rules关联文档给出该标志的准确定义当cache_api_request_cf_overrides_cache_rules被启用时传入Cache API的请求的cf对象中指定的缓存设置将覆盖Cache Rules。这仅适用于用户自有user-owned或灰云grey-clouded站点。该标志的关键属性如下属性值标志名称cache_api_request_cf_overrides_cache_rules启用标志cache_api_request_cf_overrides_cache_rules关闭标志no_cache_api_request_cf_overrides_cache_rules启用日期enable_date2025-05-19排序日期sort_date2025-05-19作用范围仅限 Cache API注意这里的措辞——传入Cache API的请求。所谓 Cache API指的是let cache caches.default; // 写入缓存 await cache.put(request, response); // 读取缓存 const cached await cache.match(request); // 删除缓存 await cache.delete(request);也就是说cf覆盖规则只有在通过caches.default.put()/caches.default.match()等 Cache API 方法传入请求时才生效。使用fetch()API 发起子请求时走的是另一套对应的标志见下文。作用范围仅限用户自有或灰云站点文档同时强调该覆盖行为只适用于用户自有user-owned或灰云grey-clouded站点。所谓灰云指域名未通过 Cloudflare 代理即 DNS 记录未开启橙色云朵的场景。对于完全由 Cloudflare 代理橙云的站点该标志的行为不受影响。这一点在编写依赖cf缓存设置覆盖缓存规则的 Worker 时需要特别留意——灰云场景下cf对象的缓存属性才能作为覆盖缓存的依据。与 Fetch API 对应标志的关系文档明确指出这是request_cf_overrides_cache_rules标志适用于fetch()API在 Cache API 上的对应物。request_cf_overrides_cache_rules的语义在仓库的 fetch-api-request-cf-overrides-cache-rules.md 中有完整描述该标志改变了通过 Fetch API 请求资源时的缓存行为。request.cf对象中指定的缓存设置如cacheEverything、cacheTtl现在优先于任何已配置的 Cache Rules。两个标志形成对称关系分别覆盖 Worker 与缓存交互的两种方式API兼容性标志覆盖对象Fetch APIfetch()cf属性request_cf_overrides_cache_rules缓存规则Cache APIcaches.default.put()/caches.default.match()cache_api_request_cf_overrides_cache_rules缓存规则这两个标志都指向同一个目标让 Worker 脚本中的缓存设置优先于 Cache Rules。区别仅在于 Worker 使用的是哪一套 API 与缓存交互。优先级顺序Workers Cache Rules Page Rules仓库中专门讲解两者交互的文档 How Workers interact with Cache Rules 给出了明确的优先级顺序Workers 脚本设置Cache Rules缓存规则Page Rules页面规则即Workers 覆盖 Cache RulesCache Rules 覆盖 Page Rules。当同一层级的多条规则同时匹配同一请求时冲突设置由最后匹配的规则获胜last matching rule wins。举例说明假设你为example.com/foo配置了一条 Cache Rule要求绕过缓存bypass cache。与此同时你的 Workers 脚本在fetch()请求的cf对象中设置了cacheEverything: true。在对应标志启用的情况下Worker 的设置优先该响应会被缓存尽管 Cache Rule 要求绕过缓存。关键提醒如果 Worker 使用的 API 没有启用对应的标志Worker 的缓存设置会被静默忽略最终以 Cache Rules 为准。这种静默降级行为是排查缓存异常时最容易忽略的点。兼容日期行为与默认启用情况Workers 的 compatibility date兼容日期 决定哪些标志默认开启设置兼容日期后所有启用日期enable date在该日期之前含当天的标志都会自动生效。围绕缓存覆盖行为涉及三个相关标志其默认启用情况如下表标志默认启用条件前提条件request_cf_overrides_cache_rulesFetch API兼容日期 ≥2025-04-02无cache_api_compat_flags兼容日期 ≥2025-04-19无cache_api_request_cf_overrides_cache_rulesCache API兼容日期 ≥2025-05-19需先启用cache_api_compat_flags这里有一个非常关键的额外约束见 workers-cache-rules.mdxCache API 有一个额外要求cache_api_compat_flags必须被启用任何兼容性标志才能在 Cache API 上生效。没有它Cache API 会忽略所有兼容性标志——即使你在配置中显式列出了这些标志。也就是说cache_api_request_cf_overrides_cache_rules要想真正生效必须同时满足cache_api_compat_flags已启用这是 Cache API 识别兼容性标志的总开关cache_api_request_cf_overrides_cache_rules本身已启用无论是通过兼容日期自动开启还是手动加入配置。旧兼容日期的实际后果文档给出了一个典型场景某条 Cache Rule 绕过example.com/foo的缓存而 Worker 的兼容日期早于2025-04-02并通过fetch()设置了cacheEverything: true。因为兼容日期太旧request_cf_overrides_cache_rules未默认启用Cache Rule 获胜响应不会被缓存。若改用 Cache API且兼容日期早于2025-04-19cache_api_compat_flags未默认启用。此时即使你在配置中手动添加了cache_api_request_cf_overrides_cache_rules它也没有任何效果——因为 Cache API 在缺少cache_api_compat_flags时根本不识别兼容性标志。配置方式在 Worker 中启用该标志兼容性标志的配置方式与普通 Workers 标志一致参见 Compatibility flags 总览有三种途径方式一通过 Wrangler 配置文件在项目的wrangler.jsonc/wrangler.toml中设置compatibility_flags{ // 兼容日期较早需要手动显式启用相关标志 compatibility_date: 2024-12-01, compatibility_flags: [ // Cache API 识别兼容性标志的总开关 cache_api_compat_flags, // 让 Cache API 请求中的 cf 缓存设置覆盖 Cache Rules cache_api_request_cf_overrides_cache_rules ] }如果你使用的是2025-05-19及以后的兼容日期上述两个标志已默认启用无需手动声明。若你的兼容日期恰好跨过启用节点但希望关闭该行为可以使用对应的关闭标志{ compatibility_date: 2025-05-19, compatibility_flags: [ no_cache_api_request_cf_overrides_cache_rules ] }方式二通过 Cloudflare Dashboard在 Cloudflare 控制台的 Workers 设置Workers 服务 → 设置 → 兼容性标志中手动添加或移除该标志。方式三通过 Cloudflare API使用 Workers Script API 或 Workers Versions API 上传 Worker 时在请求体的metadata字段中携带兼容性标志。实战示例利用cf覆盖缓存规则下面是一个完整的实战示例展示在启用cache_api_request_cf_overrides_cache_rules后Cache API 请求中的cf缓存设置如何覆盖 Cache Rules。假设场景example.com/foo上配置了一条绕过缓存的 Cache Rule但我们希望某个 Worker 对foo路径强制缓存。export default { async fetch(request) { const url new URL(request.url); // 构造带 cf 缓存设置的新请求 const cacheRequest new Request(url.toString(), { method: GET, cf: { // 强制 Cloudflare 缓存该响应无视响应头中的缓存指令 cacheEverything: true, // 缓存 1 小时 cacheTtl: 3600, // 按状态码差异化缓存200-299 缓存 1 小时404 缓存 60 秒 cacheTtlByStatus: { 200-299: 3600, 404: 60, 500-599: 0 }, }, }); const cache caches.default; // 先从缓存读取 let cached await cache.match(cacheRequest); if (cached) { return cached; } // 未命中则回源并写入缓存 const response await fetch(url.toString()); await cache.put(cacheRequest, response.clone()); return response; }, };在上述代码中cacheRequest的cf对象指定了缓存设置。当cache_api_request_cf_overrides_cache_rules生效时这些设置会覆盖那条绕过缓存的 Cache Rule使响应被真正缓存。反之若该标志未启用cf中的缓存设置会被静默忽略Cache Rule 仍将绕过缓存。关于这些cf属性的语义来自 Request 文档中的cf属性cacheEverythingboolean默认false把所有内容当作静态内容处理缓存所有默认缓存文件类型之外的内容同时尊重源站返回的缓存头。等价于 Page Rule 中的Cache Everything设置。仅适用于GET和HEAD请求。cacheTtlnumber强制 Cloudflare 缓存该响应无视响应上的任何缓存头。等价于同时设置Edge Cache TTL与Cache LevelCache Everything两条 Page Rule。取值必须为 0 或正数0表示缓存内容立即过期。仅适用于GET和HEAD请求。cacheTtlByStatus{ [key: string]: number }按响应状态码选择 TTL覆盖源站发送的缓存指令。例如{ 200-299: 86400, 404: 1, 500-599: 0 }。取值可为任意整数含 0 与负数0表示立即过期负数表示完全不要缓存。仅适用于GET和HEAD请求。使用 Cache API 时的注意事项在实战中结合该标志使用 Cache API 时还需留意以下来自 Cache API 文档 的行为约束cache.put的有效性校验传入的request必须是GET方法response的 status 不能是206 Partial Contentresponse不能包含Vary: *头否则会抛出错误。Set-Cookie响应不缓存带Set-Cookie头的响应默认永不缓存。如需缓存需先删除该头或设置Cache-Control: privateSet-Cookie。cache.put的静默拒绝当缓存键不含查询字符串例如通过自定义缓存键剥离了 query string且重定向响应的Location头包含请求的查询字符串时301/302重定向响应会被静默拒绝——这是缓存投毒cache poisoning的缓解措施。此限制不适用于.workers.dev域名。cache.match不回源cache.match()永远不会向源站发起子请求。未命中缓存时返回的 Promise 以undefined兑现底层504会出现在 Cloudflare Logs 中RequestSource为edgeWorkerCacheAPI。stale-while-revalidate与stale-if-error这两个指令在cache.put/cache.match中不受支持。Cache API 的缓存不跨数据中心复制写入某个入口数据中心的内容不会自动出现在其他数据中心除非在那里被显式创建。常见排查路径如果你启用了该标志却发现cf缓存设置没有覆盖 Cache Rule可按以下顺序排查检查是否为 Cache API确认使用的是caches.default.put()/match()而不是fetch()。如果是fetch()请改用request_cf_overrides_cache_rules标志。检查cache_api_compat_flags是否启用这是 Cache API 的总开关。缺少它其他标志全部无效。检查兼容日期确认兼容日期是否 ≥2025-05-19或是否在compatibility_flags中手动声明了该标志以及no_前缀的关闭标志没有误加。检查站点类型确认站点属于用户自有或灰云站点因为该覆盖行为仅适用于这两类场景。检查请求方法cacheEverything/cacheTtl等属性仅对GET和HEAD请求生效。总结cache_api_request_cf_overrides_cache_rules是 Cloudflare Workers 缓存体系中Worker 优先于 Cache Rules这一原则在 Cache API 上的落点。它与request_cf_overrides_cache_rulesFetch API 对应物共同构成了 Worker 侧缓存设置覆盖缓存规则的完整能力。在实际使用中务必同时确认cache_api_compat_flags已启用、兼容日期满足默认启用条件或已手动声明标志并留意该行为仅适用于用户自有或灰云站点。理解这三层约束才能在生产环境中可靠地让 Worker 的cf缓存设置真正说了算。【免费下载链接】cloudflare-docsCloudflare’s documentation项目地址: https://gitcode.com/GitHub_Trending/cl/cloudflare-docs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cloudflare Workers 兼容性标志解析：让 Cache API 请求中的 `cf` 缓存设置覆盖 Cache Rules
Cloudflare Workers 兼容性标志解析让 Cache API 请求中的cf缓存设置覆盖 Cache Rules【免费下载链接】cloudflare-docsCloudflare’s documentation项目地址: https://gitcode.com/GitHub_Trending/cl/cloudflare-docs导读本篇文章以 Cloudflare Docs 仓库中的兼容性标志文档 cache-api-request-cf-overrides-cache-rules.md 为核心深入讲解cache_api_request_cf_overrides_cache_rules这个兼容性标志compatibility flag的语义、启用方式、生效前提与实际影响。读完本文你将掌握Workers 的 Cache APIcaches.default.put()/caches.default.match()与 Cache Rules缓存规则之间的优先级关系如何通过cf对象中的cacheEverything、cacheTtl等缓存设置覆盖缓存规则以及在不同 compatibility date 下该行为如何受标志开关的默认状态控制。背景Cache API、cf对象与 Cache Rules在 Cloudflare Workers 中有三套机制会共同影响某个请求/响应是否被缓存、缓存多久Cache API通过caches.default.put()、caches.default.match()等方法在 Worker 内以编程方式读写 Cloudflare 全局网络缓存。它是一套独立的缓存接口与让 Cloudflare 直接缓存 Worker 响应的 Workers Caching 机制互相独立见 Cache API 文档。cf对象在fetch()请求或 Cache API 的request参数上携带cf属性可声明本次请求的缓存意图例如cacheEverything: true、cacheTtl: 86400、cacheTtlByStatus等见 Request 文档中的cf属性。Cache Rules在 Cloudflare 控制台或 API 中配置的缓存规则用于调整哪些内容可被缓存、缓存多久、缓存在哪里等设置见 Cache Rules 文档。当这三者同时作用于同一个请求时谁的设置说了算答案由本文的主角——兼容性标志cache_api_request_cf_overrides_cache_rules——决定。标志定义Cache API 请求中的cf设置覆盖 Cache Rules关联文档给出该标志的准确定义当cache_api_request_cf_overrides_cache_rules被启用时传入Cache API的请求的cf对象中指定的缓存设置将覆盖Cache Rules。这仅适用于用户自有user-owned或灰云grey-clouded站点。该标志的关键属性如下属性值标志名称cache_api_request_cf_overrides_cache_rules启用标志cache_api_request_cf_overrides_cache_rules关闭标志no_cache_api_request_cf_overrides_cache_rules启用日期enable_date2025-05-19排序日期sort_date2025-05-19作用范围仅限 Cache API注意这里的措辞——传入Cache API的请求。所谓 Cache API指的是let cache caches.default; // 写入缓存 await cache.put(request, response); // 读取缓存 const cached await cache.match(request); // 删除缓存 await cache.delete(request);也就是说cf覆盖规则只有在通过caches.default.put()/caches.default.match()等 Cache API 方法传入请求时才生效。使用fetch()API 发起子请求时走的是另一套对应的标志见下文。作用范围仅限用户自有或灰云站点文档同时强调该覆盖行为只适用于用户自有user-owned或灰云grey-clouded站点。所谓灰云指域名未通过 Cloudflare 代理即 DNS 记录未开启橙色云朵的场景。对于完全由 Cloudflare 代理橙云的站点该标志的行为不受影响。这一点在编写依赖cf缓存设置覆盖缓存规则的 Worker 时需要特别留意——灰云场景下cf对象的缓存属性才能作为覆盖缓存的依据。与 Fetch API 对应标志的关系文档明确指出这是request_cf_overrides_cache_rules标志适用于fetch()API在 Cache API 上的对应物。request_cf_overrides_cache_rules的语义在仓库的 fetch-api-request-cf-overrides-cache-rules.md 中有完整描述该标志改变了通过 Fetch API 请求资源时的缓存行为。request.cf对象中指定的缓存设置如cacheEverything、cacheTtl现在优先于任何已配置的 Cache Rules。两个标志形成对称关系分别覆盖 Worker 与缓存交互的两种方式API兼容性标志覆盖对象Fetch APIfetch()cf属性request_cf_overrides_cache_rules缓存规则Cache APIcaches.default.put()/caches.default.match()cache_api_request_cf_overrides_cache_rules缓存规则这两个标志都指向同一个目标让 Worker 脚本中的缓存设置优先于 Cache Rules。区别仅在于 Worker 使用的是哪一套 API 与缓存交互。优先级顺序Workers Cache Rules Page Rules仓库中专门讲解两者交互的文档 How Workers interact with Cache Rules 给出了明确的优先级顺序Workers 脚本设置Cache Rules缓存规则Page Rules页面规则即Workers 覆盖 Cache RulesCache Rules 覆盖 Page Rules。当同一层级的多条规则同时匹配同一请求时冲突设置由最后匹配的规则获胜last matching rule wins。举例说明假设你为example.com/foo配置了一条 Cache Rule要求绕过缓存bypass cache。与此同时你的 Workers 脚本在fetch()请求的cf对象中设置了cacheEverything: true。在对应标志启用的情况下Worker 的设置优先该响应会被缓存尽管 Cache Rule 要求绕过缓存。关键提醒如果 Worker 使用的 API 没有启用对应的标志Worker 的缓存设置会被静默忽略最终以 Cache Rules 为准。这种静默降级行为是排查缓存异常时最容易忽略的点。兼容日期行为与默认启用情况Workers 的 compatibility date兼容日期 决定哪些标志默认开启设置兼容日期后所有启用日期enable date在该日期之前含当天的标志都会自动生效。围绕缓存覆盖行为涉及三个相关标志其默认启用情况如下表标志默认启用条件前提条件request_cf_overrides_cache_rulesFetch API兼容日期 ≥2025-04-02无cache_api_compat_flags兼容日期 ≥2025-04-19无cache_api_request_cf_overrides_cache_rulesCache API兼容日期 ≥2025-05-19需先启用cache_api_compat_flags这里有一个非常关键的额外约束见 workers-cache-rules.mdxCache API 有一个额外要求cache_api_compat_flags必须被启用任何兼容性标志才能在 Cache API 上生效。没有它Cache API 会忽略所有兼容性标志——即使你在配置中显式列出了这些标志。也就是说cache_api_request_cf_overrides_cache_rules要想真正生效必须同时满足cache_api_compat_flags已启用这是 Cache API 识别兼容性标志的总开关cache_api_request_cf_overrides_cache_rules本身已启用无论是通过兼容日期自动开启还是手动加入配置。旧兼容日期的实际后果文档给出了一个典型场景某条 Cache Rule 绕过example.com/foo的缓存而 Worker 的兼容日期早于2025-04-02并通过fetch()设置了cacheEverything: true。因为兼容日期太旧request_cf_overrides_cache_rules未默认启用Cache Rule 获胜响应不会被缓存。若改用 Cache API且兼容日期早于2025-04-19cache_api_compat_flags未默认启用。此时即使你在配置中手动添加了cache_api_request_cf_overrides_cache_rules它也没有任何效果——因为 Cache API 在缺少cache_api_compat_flags时根本不识别兼容性标志。配置方式在 Worker 中启用该标志兼容性标志的配置方式与普通 Workers 标志一致参见 Compatibility flags 总览有三种途径方式一通过 Wrangler 配置文件在项目的wrangler.jsonc/wrangler.toml中设置compatibility_flags{ // 兼容日期较早需要手动显式启用相关标志 compatibility_date: 2024-12-01, compatibility_flags: [ // Cache API 识别兼容性标志的总开关 cache_api_compat_flags, // 让 Cache API 请求中的 cf 缓存设置覆盖 Cache Rules cache_api_request_cf_overrides_cache_rules ] }如果你使用的是2025-05-19及以后的兼容日期上述两个标志已默认启用无需手动声明。若你的兼容日期恰好跨过启用节点但希望关闭该行为可以使用对应的关闭标志{ compatibility_date: 2025-05-19, compatibility_flags: [ no_cache_api_request_cf_overrides_cache_rules ] }方式二通过 Cloudflare Dashboard在 Cloudflare 控制台的 Workers 设置Workers 服务 → 设置 → 兼容性标志中手动添加或移除该标志。方式三通过 Cloudflare API使用 Workers Script API 或 Workers Versions API 上传 Worker 时在请求体的metadata字段中携带兼容性标志。实战示例利用cf覆盖缓存规则下面是一个完整的实战示例展示在启用cache_api_request_cf_overrides_cache_rules后Cache API 请求中的cf缓存设置如何覆盖 Cache Rules。假设场景example.com/foo上配置了一条绕过缓存的 Cache Rule但我们希望某个 Worker 对foo路径强制缓存。export default { async fetch(request) { const url new URL(request.url); // 构造带 cf 缓存设置的新请求 const cacheRequest new Request(url.toString(), { method: GET, cf: { // 强制 Cloudflare 缓存该响应无视响应头中的缓存指令 cacheEverything: true, // 缓存 1 小时 cacheTtl: 3600, // 按状态码差异化缓存200-299 缓存 1 小时404 缓存 60 秒 cacheTtlByStatus: { 200-299: 3600, 404: 60, 500-599: 0 }, }, }); const cache caches.default; // 先从缓存读取 let cached await cache.match(cacheRequest); if (cached) { return cached; } // 未命中则回源并写入缓存 const response await fetch(url.toString()); await cache.put(cacheRequest, response.clone()); return response; }, };在上述代码中cacheRequest的cf对象指定了缓存设置。当cache_api_request_cf_overrides_cache_rules生效时这些设置会覆盖那条绕过缓存的 Cache Rule使响应被真正缓存。反之若该标志未启用cf中的缓存设置会被静默忽略Cache Rule 仍将绕过缓存。关于这些cf属性的语义来自 Request 文档中的cf属性cacheEverythingboolean默认false把所有内容当作静态内容处理缓存所有默认缓存文件类型之外的内容同时尊重源站返回的缓存头。等价于 Page Rule 中的Cache Everything设置。仅适用于GET和HEAD请求。cacheTtlnumber强制 Cloudflare 缓存该响应无视响应上的任何缓存头。等价于同时设置Edge Cache TTL与Cache LevelCache Everything两条 Page Rule。取值必须为 0 或正数0表示缓存内容立即过期。仅适用于GET和HEAD请求。cacheTtlByStatus{ [key: string]: number }按响应状态码选择 TTL覆盖源站发送的缓存指令。例如{ 200-299: 86400, 404: 1, 500-599: 0 }。取值可为任意整数含 0 与负数0表示立即过期负数表示完全不要缓存。仅适用于GET和HEAD请求。使用 Cache API 时的注意事项在实战中结合该标志使用 Cache API 时还需留意以下来自 Cache API 文档 的行为约束cache.put的有效性校验传入的request必须是GET方法response的 status 不能是206 Partial Contentresponse不能包含Vary: *头否则会抛出错误。Set-Cookie响应不缓存带Set-Cookie头的响应默认永不缓存。如需缓存需先删除该头或设置Cache-Control: privateSet-Cookie。cache.put的静默拒绝当缓存键不含查询字符串例如通过自定义缓存键剥离了 query string且重定向响应的Location头包含请求的查询字符串时301/302重定向响应会被静默拒绝——这是缓存投毒cache poisoning的缓解措施。此限制不适用于.workers.dev域名。cache.match不回源cache.match()永远不会向源站发起子请求。未命中缓存时返回的 Promise 以undefined兑现底层504会出现在 Cloudflare Logs 中RequestSource为edgeWorkerCacheAPI。stale-while-revalidate与stale-if-error这两个指令在cache.put/cache.match中不受支持。Cache API 的缓存不跨数据中心复制写入某个入口数据中心的内容不会自动出现在其他数据中心除非在那里被显式创建。常见排查路径如果你启用了该标志却发现cf缓存设置没有覆盖 Cache Rule可按以下顺序排查检查是否为 Cache API确认使用的是caches.default.put()/match()而不是fetch()。如果是fetch()请改用request_cf_overrides_cache_rules标志。检查cache_api_compat_flags是否启用这是 Cache API 的总开关。缺少它其他标志全部无效。检查兼容日期确认兼容日期是否 ≥2025-05-19或是否在compatibility_flags中手动声明了该标志以及no_前缀的关闭标志没有误加。检查站点类型确认站点属于用户自有或灰云站点因为该覆盖行为仅适用于这两类场景。检查请求方法cacheEverything/cacheTtl等属性仅对GET和HEAD请求生效。总结cache_api_request_cf_overrides_cache_rules是 Cloudflare Workers 缓存体系中Worker 优先于 Cache Rules这一原则在 Cache API 上的落点。它与request_cf_overrides_cache_rulesFetch API 对应物共同构成了 Worker 侧缓存设置覆盖缓存规则的完整能力。在实际使用中务必同时确认cache_api_compat_flags已启用、兼容日期满足默认启用条件或已手动声明标志并留意该行为仅适用于用户自有或灰云站点。理解这三层约束才能在生产环境中可靠地让 Worker 的cf缓存设置真正说了算。【免费下载链接】cloudflare-docsCloudflare’s documentation项目地址: https://gitcode.com/GitHub_Trending/cl/cloudflare-docs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考