配方：不破坏登录与 API 的 Cache Rules
先绕过登录、账号与写接口，再只缓存公开内容，并用响应头和双客户端验证规则。
编辑与核验：橙宝书编辑团队 ·
安全顺序
先定义绝不能缓存的路径和响应，再为窄范围公开内容开启缓存。登录、账号、购物车、结账、管理后台、带身份的 API 和写请求默认绕过；不要从“Cache Everything 全站打开”开始。
先填这张矩阵
| 路径类别 | 示例 | 默认动作 | 验证重点 |
|---|---|---|---|
| 静态指纹资源 | /assets/app.abc123.js | 缓存，可使用较长 TTL | 多次请求变为 HIT，版本 URL 可更新 |
| 公开内容 | /blog/*、公开产品页 | 按源站头或明确规则缓存 | 未登录与不同客户端看到一致公开内容 |
| 身份与交易 | /login、/account/*、/cart/*、/checkout/* | 绕过 | Set-Cookie、CSRF、用户数据不进入共享缓存 |
| API | /api/* | 默认绕过；只给明确的公开 GET 单独建规则 | method、Authorization、Cookie 与响应隐私 |
| 管理与预览 | /admin/*、/preview/* | 绕过 | 草稿和管理响应不被匿名读取 |
按风险从低到高发布
保存变更前响应头
curl -sS -D before.txt -o /dev/null https://example.com/assets/app.css
curl -sS -D - -o /dev/null https://example.com/account记录 URL、状态、CF-Cache-Status、Cache-Control、Set-Cookie、Vary 和时间。不要先清全站缓存。
建立高优先级绕过规则
先匹配登录、账号、购物车、结账、管理、预览和带身份的 API。写方法不应因为 URL 看起来公开而进入共享缓存。实际条件以当前 Cache Rules 表达式编辑器为准，并把每条规则的业务所有者写进变更记录。
只给一个公开资源集合启用缓存
首轮选择带内容哈希的静态资源，或一个确认不含个人数据的公开路径。不要同时改变缓存键、源站头、TTL 和全部路径；一次只验证一个假设。
分别验证匿名与登录客户端
用无 Cookie 的新会话连续请求两次公开资源，再用两个不同测试账号访问受保护页面。成功标准不仅是公开资源出现 HIT，还包括账号 A 永远看不到账号 B 的内容，登录和 CSRF 流程不被破坏。
再处理过期与重新验证
需要 stale-while-revalidate 时，先理解异步重新验证：过期对象的首个请求可能看到 UPDATING。must-revalidate、proxy-revalidate、s-maxage 与 no-cache 会影响是否允许提供陈旧响应，应按内容新鲜度与隐私要求决定，而不是只追求命中率。
Cache Everything 可能破坏会话
过度激进的缓存会干扰 Set-Cookie、登录状态和 CSRF。若问题出现在开启全页缓存之后，先缩小或关闭该规则并恢复身份路径，再调查源站；不要通过删除安全 Cookie 来让页面命中缓存。
发布与回滚门禁
- 规则只覆盖已列出的公开路径，身份路径有更高优先级的绕过。
- 至少两个测试账号完成登录、退出、查看账号页与写操作。
- 公开资源在相同 URL 和条件下得到可解释的
MISS → HIT或重新验证状态。 - 出现用户数据串读、登录循环、CSRF 失败或异常
Set-Cookie时，立即停用新规则。 - 回滚后重复变更前的只读请求，确认响应头与业务恢复。
若响应没有按预期命中，继续按 CF-Cache-Status 排障保留证据。
官方来源
这篇内容帮你完成目标了吗？
内测反馈只在当前浏览器生成，不会自动上传。