区分 no-store、private 与 no-cache，并用双账号、匿名访问和退出后的测试矩阵排查共享缓存泄露。
订单页、个人资料页和管理后台一旦被共享缓存错误复用，影响可能超过短暂的数据过期。排查时不要只看某个响应头，而应验证不同身份是否会收到彼此的数据。
三个指令对应不同目标
MDN 对 Cache-Control 的定义是：no-store 要求不存储响应；private 阻止共享缓存存储，但允许浏览器私有缓存；no-cache 允许存储，只是在复用前必须验证。把 no-cache 当作“绝不缓存”，容易留下理解偏差。缓存平台的覆盖规则也需要一起检查。
准备一份不含真实用户数据的测试集
在授权测试环境创建账号 A 和 B，分别写入明显不同的测试标记。使用两个隔离的浏览器会话，另开匿名会话。测试时保持同一路径及参数；不要通过随意加随机参数绕开缓存，否则可能掩盖问题。
| 顺序 | 请求 | 应观察的结果 |
|---|---|---|
| 1 | A 访问个人页 | 只出现 A 的测试标记 |
| 2 | B 访问相同地址 | 只出现 B 的测试标记 |
| 3 | 匿名访问 | 拒绝访问或返回公开页面 |
| 4 | A 退出后再次访问 | 不能通过服务端响应取得私密内容 |
发现问题后先隔离再修复
优先停止受影响私密路径的共享缓存，按平台能力清理相关缓存，再核对应用响应与边缘配置。保留不含敏感正文的时间、缓存状态和请求标识，帮助确定影响范围。不要把清理缓存当成永久修复：错误规则仍会让内容再次进入缓存。
复测应覆盖成功响应、错误页、跳转和不同语言或设备分支。对确实需要缓存的个性化内容，应明确缓存键中的身份边界，并由安全与业务共同验收；如果说不清隔离机制，先采用更保守的策略。
参考：MDN：Cache-Control。核对日期：2026年10月4日。
