本质是缓存键未区分用户身份，导致不同用户请求命中同一缓存；必须根据业务引入哈希后的用户标识（如md5($cookie_user_id)），并实测响应体差异，避免误用全局缓存区域或未清洗的动态字段。
不同用户看到相同缓存内容，本质是缓存键没区分用户身份，导致本该隔离的响应被混存——比如用户 A 的个人中心页被缓存后，用户 B 请求同一 URL 也命中了它。这不是缓存“太强”，而是键“太糙”。关键在确认用户标识是否参与缓存决策，以及是否被正确处理。
检查缓存键是否遗漏用户维度
默认的 $scheme$host$request_uri 完全不包含用户信息，所有用户请求都会生成同一个 key。必须根据业务判断是否需要区分：
- 公开页面（如首页、商品列表）可不区分用户，用 URL 级缓存即可
- 登录态接口（如
/api/user/profile）、个性化推荐、权限相关接口，必须引入用户标识 - 优先使用哈希后的
md5($cookie_user_id)或md5($http_x_user_id)，避免明文泄露或 key 膨胀 - 绝对不要直接写
$cookie_sessionid或完整$http_authorization——除非你明确要按 session 精确隔离
验证后端是否真返回了不同内容
别假设“应该不同”，要实测。用 curl 构造两个已登录用户的请求，仅更换 Cookie 或 Token，对比响应体：
curl -H "Cookie: user_id=123" https://api.example.com/profilecurl -H "Cookie: user_id=456" https://api.example.com/profile- 用
sha256sum比对响应体哈希值；若一致，说明后端本就没区分用户，缓存键再准也没用 - 若响应体不同但缓存命中率高，说明 key 没带用户标识，或用了未清洗的动态字段（如带时间戳的 header）干扰了 key 稳定性
排查是否误用全局缓存区域或路径冲突
即使 key 包含用户信息，如果多个租户或环境共用同一个 keys_zone 或物理缓存路径，仍可能交叉污染：
- 检查
proxy_cache_path是否为不同租户配置了独立路径，例如/var/cache/nginx/tenant-a和/var/cache/nginx/tenant-b - 确认
proxy_cache指令引用的 zone 名称是否与 key 设计匹配，避免 A 服务的 key 写入 B 服务的 zone - 多租户场景下，缓存键应显式携带租户标识，例如
"tenant:$http_x_tenant_id:$scheme$host$request_uri:uid_$md5_user_id" - 通过日志格式
log_format cache '$cache_key - $upstream_cache_status';查看实际生成的 key，确认 tenant_id 和 uid 是否真实存在且稳定
快速定位是否发生缓存污染
不用等线上事故，用三步法现场验证：
- 临时把缓存键设为固定值（如
"debug_user_shared"），发起两个不同用户的请求，观察是否都返回X-Cache-Status: HIT—— 若是，说明当前配置确实不区分用户 - 恢复正常 key 后，开启
add_header X-Cache-Key $cache_key;，用curl -I查看响应头，确认 key 中是否包含用户哈希段且两次请求值不同 - 检查 Nginx access 日志中
$upstream_cache_status字段：若大量MISS后突然出现HIT，且 key 中用户段相同，说明隔离生效；若 key 不同但响应体相同，说明后端未个性化，应优化上游而非缓存
