同一个网址，未登录者看到公开首页，登录者却可能看到账户名称、订单或专属推荐。若共享缓存只按网址取内容，登录用户的页面就有机会被错误地提供给其他人。缓存键如何处理登录态Cookie与个性化页面，核心不是把所有 Cookie 一股脑塞进键里，而是先判断响应能否共享，再决定用哪些请求特征区分。
先划清公共内容和私人响应
缓存键决定不同请求是否命中同一份缓存；它本身并不能替代访问控制。新闻正文、公开帮助页等对所有访客相同的内容，通常可以走公共缓存。账户资料、购物车、订单状态等依赖当前用户的数据，应由应用按登录身份读取，并避免进入供多人共用的缓存。
对于私人响应，可按场景设置 Cache-Control: private，表示不应由共享缓存保存；对高度敏感或必须保证每次重新获取的内容，可考虑 no-store。具体策略还要核对浏览器、反向代理和 CDN 的缓存规则，因为某一层的自定义配置可能覆盖或忽略源站的意图。
三种 Cookie 处理方式，适用场景不同
不区分 Cookie：只用于确实公共的响应
如果页面内容不读取登录 Cookie，缓存键可以不包含 Cookie。这样命中率通常较高，也不会因为分析统计、语言偏好等无关 Cookie 产生大量副本。前提是应用确认这些 Cookie 不会改变响应正文、状态码或访问权限。
按登录状态分流：适合匿名与登录版页面有明确边界时
若登录与匿名访客需要不同页面，可以在缓存层识别会话 Cookie 是否存在，将请求分为匿名和登录两类。匿名版本可共享；登录版本通常应绕过共享缓存或设为私人响应。不要仅凭 Cookie 存在就认定用户已通过认证，身份验证仍应由应用完成。
按完整 Cookie 区分：通常代价高且容易出错
把整个 Cookie 请求头加入缓存键，理论上能区分不同 Cookie 组合，但浏览器可能同时发送会话、语言、实验分组等多个 Cookie，组合变化会造成缓存碎片，降低命中率。更重要的是，它不自动证明缓存配置安全：规则遗漏某个影响内容的 Cookie，仍可能导致串内容。只有确认需要且能控制 Cookie 集合时，才考虑精确纳入相关字段。
配置时按这个顺序检查
- 盘点响应依赖。逐个检查页面是否读取会话标识、权限、地区或语言 Cookie；确认哪些字段会改变正文、重定向和状态码。
- 划分路由。把公开页面与账户、购物车、订单等个性化路径分开配置。不能仅凭 URL 判断的，还要检查接口返回是否包含用户数据。
- 设置缓存策略。公共响应只按必要维度建立缓存键；登录个人页面设置私人策略或对共享缓存绕过。若使用语言、设备类型等维度，应确保它们确实影响响应，并同步处理内容变化。
- 验证两类请求。分别用无会话 Cookie 和有效登录会话请求同一页面，检查响应内容、缓存状态及响应头。再用两个不同账户重复验证，确认个人数据不会交叉。
- 检查变更后的旧对象。修改缓存键或规则后，按平台能力清理受影响的旧缓存，并检查匿名请求是否仍能命中、登录请求是否绕过共享缓存。
容易忽略的边界问题
响应带有 Set-Cookie 并不等于所有缓存系统都会自动拒绝缓存；应查看具体代理或 CDN 的默认行为与覆盖规则。反过来，Cookie 中含有会话令牌，也不代表它必须进入缓存键：若登录响应不应共享，更稳妥的做法往往是直接绕过共享缓存，而不是为每个用户制造一份共享缓存对象。
还要留意缓存键之外的请求头。若内容随语言协商变化，源站可能通过 Vary 声明相应维度；代理是否遵循该声明仍需核验。不要把随机追踪参数、无关 Cookie 或完整用户标识无差别加入键中，否则会扩大缓存对象数量，并增加配置维护难度。
常见问题
登录用户的所有页面都要禁用缓存吗？
不一定。可以缓存明确公开且不含个人信息的资源；但账户资料等私人响应不应进入多人共用的缓存。浏览器本地缓存与共享缓存也应分别评估。
把用户 ID 加入缓存键能防止串数据吗？
它能区分对象，但不等于安全策略完整，还会增加缓存副本。对个人页面，通常应优先绕过共享缓存或使用私人缓存策略。
只有一个登录 Cookie，能否直接按它分键？
可以作为设计选项，但要确认该 Cookie 确实决定内容、值的变化可控，并验证不同用户的响应绝不会进入同一共享对象。不能确认时，登录请求绕过共享缓存更稳妥。
归根结底，缓存键如何处理登录态Cookie与个性化页面，先看响应是否允许共享，再挑选真正影响公共内容的区分维度。个人数据走私人响应，公共内容保留合理缓存，最后用匿名请求和不同账户验证边界，才能兼顾安全与命中率。
