Cloudflare Workers 兼容性标志cache_no_cache_enabled全解析在fetch()中启用标准cache: no-cache【免费下载链接】cloudflare-docsCloudflare’s documentation项目地址: https://gitcode.com/GitHub_Trending/cl/cloudflare-docscache_no_cache_enabled是 Cloudflare Workers 在 2025-08-07 随兼容性日期默认启用的一组兼容性标志它让开发者可以在 Worker 发起的子请求中通过fetch()与Request初始化参数指定标准 HTTP 语义的cache: no-cache从而强制 Cloudflare 缓存与源站重新验证。本文以仓库中的 cache-no-cache.md 为骨架结合 fetch() API 文档 与兼容性标志的配置文档完整讲解该标志的前置条件、开启后的请求行为、缓存重验证流程、代码示例以及如何通过 Wrangler、Dashboard 与 API 开关它。读完你将能正确地在 Worker 中强制按需重验证源站资源并理解它与cache: no-store的区别。标志总览front matter 中的关键元数据该文档的 front matter 定义了标志的完整元信息是理解其生命周期与开关方式的起点字段值含义nameEnablecache: no-cacheHTTP standard API标志的人类可读名称sort_date2025-08-07用于按时间排序展示的日期enable_date2025-08-07该标志自该兼容性日期起默认启用的日期enable_flagcache_no_cache_enabled显式启用该行为的兼容性标志名disable_flagcache_no_cache_disabled显式禁用该行为的兼容性标志名从仓库的 compatibility-flags.ts 可以看到所有兼容性标志的 schema 统一包含name、enable_date、enable_flag、disable_flag、sort_date以及可选的experimental字段。而 compatibility-flags.json.ts 则把src/content/compatibility-flags/目录下全部标志聚合为一个 JSON 端点省略sort_date并将正文作为description输出这意味着本文档的内容同样会被程序化消费例如供 Dashboard 或自动化工具展示。关键事实由于enable_date与sort_date均为2025-08-07对于compatibility_date设定在2025-08-07或之后的 Worker该行为默认开启无需任何配置旧 Worker 则需要显式加入cache_no_cache_enabled。未启用时的行为TypeError保护文档明确说明了未开启时的兜底逻辑当未启用cache_no_cache_enabled或设置了cache_option_disabled时Workers 运行时会抛出TypeError错误信息为Unsupported cache mode: no-cache。这包含两种触发条件未启用cache_no_cache_enabled例如 Worker 的compatibility_date早于2025-08-07且没有显式加入该标志设置了cache_option_disabled这是cache_option_enabledcache: no-store支持的禁用标志。由于cache: no-cache与cache: no-store同属fetch()的cache选项体系当no-store支持被整体关闭时no-cache也会一并失效并抛出TypeError。同时仓库中的 fetch() API 文档 对这一约束给出了更完整的表述cache选项的合法取值只有undefined | no-store | no-cache三种指定任何其他值如浏览器端的default、reload、force-cache等都会抛出TypeError错误信息为Unsupported cache mode: attempted-cache-mode。启用后的效果重新验证而非绕过缓存文档将no-cache的行为归纳为两点所有请求都会附带Pragma: no-cache与Cache-Control: no-cache两个请求头向源站明示请返回可用的缓存校验信息对非 Cloudflare 托管的源站发起的子请求会强制 Cloudflare 的缓存与源站重新验证revalidate。这与no-store有本质区别no-store由cache_option_enabled标志支持参见 cache-no-store.md同样会给请求加上Pragma: no-cache与Cache-Control: no-cache但对非 Cloudflare 托管源站的行为是完全绕过 Cloudflare 缓存而no-cache则保留缓存命中可能性只是强制在响应前向源站确认缓存是否仍然有效。需要特别注意的是该行为作用于Worker 内部发起的子请求subrequest而不是直接控制客户端到 Worker 的请求缓存策略。缓存重验证的完整流程文档给出了启用后请求经过 Cloudflare 缓存时的三步决策过程先在 Cloudflare 缓存中查找匹配项命中时无论该缓存条目是新鲜的fresh还是已过期的stale都会向源站发送一个条件请求conditional request。若源站确认资源未变化则直接返回缓存版本若资源已变化则从源站下载最新内容、更新缓存并返回该新内容未命中时Worker 向源站发起标准请求并将响应写入缓存后返回。这个命中即条件请求、无视新鲜度的设计正是Cache-Control: no-cache的 HTTP 标准语义——允许使用缓存但每次使用前都必须经过源站验证从而在尽可能少回源与保证内容最新之间取得平衡。对于命中且资源未变化的场景源站只需返回 304 之类的验证响应流量成本远低于完整下载。代码示例两种指定方式文档提供了两种等价的写法均可直接复制使用。方式一在fetch()的 options 中指定const response await fetch(https://example.com, { cache: no-cache });方式二构造Request对象后传入fetch()const request new Request(https://example.com, { cache: no-cache }); const response await fetch(request);两种方式的语义完全一致cache属性既可以作为RequestInit的选项直接传入fetch()也可以在构造Request时固化到请求对象上。后者适合需要先构建、校验或复用同一个请求对象再发起的场景。如何开启或关闭该标志根据 compatibility-flags.mdx 的说明兼容性标志有三条配置通道1. 通过 Wrangler 配置文件在wrangler.jsonc或wrangler.toml中设置compatibility_date与compatibility_flags{ // 将兼容性日期固定在 2025-08-07 之前以便按需逐项开启新行为 compatibility_date: 2025-08-06, // 显式启用 no-cache 支持 compatibility_flags: [cache_no_cache_enabled] }若你的compatibility_date已晚于2025-08-07默认已开启但出于兼容性考虑想关闭该行为则应加入cache_no_cache_disabled{ compatibility_date: 2025-08-07, compatibility_flags: [cache_no_cache_disabled] }2. 通过 Cloudflare Dashboard在 Cloudflare Dashboard 中进入 Worker 的 Settings → Compatibility flags兼容性标志面板添加或移除对应标志即可。3. 通过 Cloudflare API调用 Workers Script API 更新 Worker或在创建新版本Workers Versions API时在请求体的metadata字段中携带compatibility_flags数组。这与该仓库 compatibility-flags.json.ts 输出的 JSON 结构保持一致。相关标志对照与选型建议为了不混淆下表将cache选项体系中的两个标志并列对照行为启用标志禁用标志默认启用日期对非 Cloudflare 源站的效果cache: no-storecache_option_enabledcache_option_disabled2024-11-11绕过 Cloudflare 缓存直接回源cache: no-cachecache_no_cache_enabledcache_no_cache_disabled2025-08-07强制与源站重新验证后再响应两者的共同点是都会在请求上附加Pragma: no-cache与Cache-Control: no-cache头且都只支持这两个取值fetch() API 文档。选型建议需要每次都拿到源站最新内容、但允许 304 复用缓存时用no-cache需要完全跳过缓存读取例如包含敏感数据、要求不可缓存的请求时用no-store如果代码中出现了这两个取值以外的cache值运行时会抛出Unsupported cache mode的TypeError请确保只使用no-store与no-cache。与 Cache API 的边界cache: no-cache作用于fetch()发起的子请求属于通过标准 HTTP 头驱动 Cloudflare 缓存决策的路径。仓库中另有面向 Cache API 的兼容性标志cache_api_request_cf_overrides_cache_rules见 cache-api-request-cf-overrides-cache-rules.md它处理的是请求cf对象中的缓存设置对缓存规则的覆盖问题仅适用于用户自有或灰云grey-clouded站点两者分工不同前者是标准 HTTP 语义的请求选项后者是 Cache API 的配置覆盖。小结cache_no_cache_enabled将标准 HTTP 的no-cache语义完整地带入了 Workers 运行时开启后Worker 内的子请求可以用fetch(url, { cache: no-cache })或new Request(url, { cache: no-cache })驱动 Cloudflare 缓存与源站做条件重验证在命中未变更资源时以极小回源成本返回最新内容。该标志自2025-08-07起默认启用可通过cache_no_cache_disabled显式关闭其完整行为、支持取值与配置方式均可在本文引用的 cache-no-cache.md、fetch() API 文档 与 兼容性标志总览 中进一步查阅。【免费下载链接】cloudflare-docsCloudflare’s documentation项目地址: https://gitcode.com/GitHub_Trending/cl/cloudflare-docs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考