同一个页面，登录用户看到购物车，访客看到公共内容；如果边缘节点把带 Cookie 的响应当成通用副本缓存，就可能把一位用户的数据返回给另一位用户。边缘节点缓存Cookie内容的配置风险，关键不在于“有没有缓存 Cookie”，而在于缓存键、响应内容和绕过规则是否一致。
配置前先区分两件事：请求中的 Cookie 会影响源站如何生成内容；响应中的 Set-Cookie 则可能创建或更新浏览器状态。边缘缓存是否忽略、保留或依据这些字段区分对象，取决于具体产品和规则，不能只凭默认行为推断。
五项风险：从用户数据到缓存稳定性
- 用户内容串用。若页面包含账户资料、购物车或订单状态，而缓存键没有区分对应的会话 Cookie，边缘节点可能将个性化响应复用于其他请求。登录后页面和账户相关接口通常应绕过共享缓存，或使用经过验证的私有缓存设计。
- 授权边界被削弱。源站可能根据 Cookie 判断访问权限。若边缘节点直接返回已缓存内容，请求可能没有按预期经过源站校验。权限页面、一次性令牌和个人文件下载，不适合仅靠 Cookie 存在与否来决定缓存。
- 缓存命中率降低。若把每个 Cookie 值都纳入缓存键，用户之间的对象会被拆分，命中率可能下降、缓存占用增加。访客标识、分析标记等 Cookie 通常不决定页面正文，可考虑在确认源站不依赖它们后，从缓存键中排除。
- 响应状态与浏览器状态不一致。缓存响应若带有 Set-Cookie，后续请求可能收到不适用于自己的状态；即使产品默认不缓存此类响应，也应核对实际规则，不能把默认值当作安全保证。
- 规则优先级造成误放行。宽泛的缓存规则可能覆盖更具体的登录或支付路径规则。路径改名、规则顺序变化后，原本绕过缓存的页面也可能被缓存。
全缓存与按规则放行，差异在哪里
| 策略 | 优点 | 限制与适用条件 |
|---|---|---|
| 忽略 Cookie，尽量缓存 | 对象更容易复用，适合确认不受登录状态影响的公共静态内容。 | 若响应实际依赖 Cookie，可能返回错误或泄露个性化内容；必须先确认页面与接口都是公共内容。 |
| 按 Cookie 或路径绕过缓存 | 可让登录、账户、购物车等请求回源处理，降低共享缓存串用风险。 | 规则需要维护，判断条件不完整会漏掉新路径；绕过范围过大也会降低命中率。 |
| 按规则缓存公共部分 | 只缓存已验证的公共页面，同时放行会话相关请求，兼顾速度与隔离。 | 需要测试缓存键、Cookie 条件、响应头和规则优先级，配置复杂度较高。 |
实际选择不必在“全缓存”和“全部回源”之间二选一。对不含个人信息、且内容一致的页面，可缓存公共副本；对读取会话状态的页面，优先绕过共享缓存。Cache-Control 中的 private 或 no-store 可表达响应缓存意图，但边缘产品仍可能有单独规则，需核对配置是否遵循这些指令。
按步骤检查配置
- 列出会话敏感路径，例如登录、账户、购物车、结账和个人资料；确认这些路径是否读取 Cookie 并返回用户专属内容。
- 查看边缘缓存规则及缓存键：哪些 Cookie 被忽略，哪些会参与区分；将不确定的路径先设置为绕过共享缓存。
- 检查源站响应头，特别留意 Cache-Control、Vary 和 Set-Cookie。不要假设 Vary: Cookie 在所有边缘产品中都会按预期建立缓存变体。
- 用两个独立浏览器会话分别访问同一 URL：先请求，再交换顺序重复测试；确认页面内容、响应头及缓存状态没有跨会话复用。
- 修改规则后观察缓存命中情况，并复测登录、退出和 Cookie 过期等状态变化。边缘节点可能保留旧对象，必要时按产品能力清理相关缓存。
常见问题
Cookie 一出现就应该绕过缓存吗？
不一定。若 Cookie 不影响响应内容，可在验证后排除它对缓存键的影响；若关联会话或权限，应绕过共享缓存或采用可靠的隔离策略。
把所有 Cookie 都加入缓存键安全吗？
这能减少不同 Cookie 请求共用对象的可能，但不能替代权限设计，还可能导致对象碎片化、命中率下降。
只看状态码能确认缓存安全吗？
不能。还要检查响应正文、缓存键、响应头和不同会话之间的结果。
应该先改哪条规则？
先识别并放行会话敏感路径，再逐步开放经过验证的公共内容。边缘节点缓存Cookie内容的配置风险，最终应通过规则审查和跨会话测试共同控制。
