登录态页面可能包含姓名、订单、账户设置等因用户而异的内容。若共享缓存把一位用户的响应发给另一位用户，问题就不只是页面显示错误，还可能涉及隐私泄露。落实登录态页面绕过缓存的配置原则时，通常应先确保个性化响应不进入共享缓存，再考虑用请求头还是路径触发绕过。
先分清“识别登录”与“决定缓存”
请求头方案，是由边缘节点、CDN 或反向代理检查请求中是否有 Cookie、Authorization 等登录凭据，再对命中的请求跳过共享缓存。路径方案，则根据 URL 目录或路由规则处理，例如把账户中心、结算流程等明确的私有区域列入绕过范围。
两者解决的是缓存层如何识别请求，并不等于应用已经正确设置响应缓存策略。浏览器缓存与共享缓存也不是一回事：页面只允许用户自己的设备暂存，不代表可以由 CDN 或代理复用。登录态页面绕过缓存的配置原则应明确区分这两种缓存。
| 方式 | 适用条件 | 主要风险 |
|---|---|---|
| 按请求头绕过 | 登录凭据稳定地出现在可检查的请求头中，缓存层能够可靠识别 | 漏掉某种认证方式，或把凭据纳入缓存键造成大量重复对象 |
| 按路径绕过 | 私有功能集中在固定路由，路径边界清楚 | 新页面或改版路由未加入规则；同一路径仍可能根据身份返回不同内容 |
请求头方案：覆盖面广，但规则必须谨慎
按 Cookie 或 Authorization 判断，适合公开页面和个人页面共用一套路由、而登录身份通过请求头传递的站点。常见做法是让带认证凭据的请求绕过共享缓存，而不是按每位用户的凭据分别缓存。后者会增加缓存对象数量，也扩大配置错误的影响范围。
需要留意：登录状态不一定只由一种 Cookie 表示，部分系统还会使用不同的会话名称或 Authorization 认证。规则若只检查其中一种，另一个入口就可能被误当成匿名请求。逐项确认应用实际使用的认证方式，并让共享缓存默认不复用个性化响应，是更稳妥的起点。
路径方案：适合边界清晰的私有区域
账户、订单、结算等功能若各有稳定路由，按路径绕过通常更容易审查，也不依赖缓存层理解身份凭据。它尤其适合团队能统一维护路由清单的系统。
但路径本身不是登录凭证。若首页或商品详情页会在登录后显示个人信息，仅绕过“账户”目录就不够；同一路径可能同时返回匿名内容和个性化内容。此外，尾部斜杠、大小写、语言前缀及新旧路由是否匹配，都应按实际路由规则核对。不要把“路径看起来私有”当作已验证的依据。
更稳妥的配置与验证步骤
- 列出页面类型：区分完全公开、登录后仍为公共内容、含用户专属数据三类，标出账户、订单、个人设置等敏感路由。
- 确认认证入口：从应用实际请求中核对登录凭据放在哪些请求头或 Cookie 中，不凭字段名称猜测。
- 先设安全边界：个性化页面不允许共享缓存复用；响应侧按需求限制浏览器缓存。可用 Cache-Control 的 private 或 no-store 表达不同限制，但具体选择需考虑页面敏感度和返回后是否允许设备暂存。
- 选择识别条件：固定私有路由优先用路径规则；身份可能出现在多种页面时，增加凭据判断。两种条件可以组合，避免单一规则漏网。
- 用不同身份实测：分别以未登录、账户甲和账户乙访问同一页面，再重复刷新并检查缓存状态及响应正文。确认甲的数据不会出现在乙的响应中，也不会把带登录信息的响应作为公共缓存命中。
- 随路由变更复核：发布新页面、调整认证方式或迁移 CDN、反向代理配置时，重新检查规则覆盖范围。
因此，没有脱离系统结构的绝对赢家：私有路由稳定且集中时，路径规则直观；认证信息跨多个页面传递时，请求头判断覆盖更灵活。多数情况下，先保证共享缓存不接触个性化响应，再用路径和请求头互补，是登录态页面绕过缓存的配置原则中更可靠的思路。
常见问题
带 Cookie 的请求一定要绕过缓存吗？
不一定。有些 Cookie 只用于语言或界面偏好，但需要确认响应确实不依赖用户身份；无法确认时，不应让共享缓存复用响应。
只按路径绕过，是否能保护登录数据？
只有当所有个性化路由都被覆盖时才可能充分。还要检查同一路径是否会因登录状态返回不同内容。
private 和 no-store 有什么区别？
private 用于限制共享缓存存储，仍可能允许浏览器私有缓存；no-store 则要求缓存不存储该响应。应结合敏感程度与使用需求决定。
配置后怎样快速发现误缓存？
用两个独立账户请求同一页面，比较响应正文及缓存命中信息；同时检查未登录访问，确保没有个性化内容泄露。