核心是切断重写对缓存键的干扰，让nginx识别“逻辑相同但url被改写”的请求为同一缓存项：1.用$scheme$host$uri$is_args$args替代$request_uri确保语义一致；2.禁用动态头参与key，除非明确需用户级隔离；3.为不同上游服务定义独立proxy_cache_path与keys_zone并显式绑定；4.统一清理上游cache-control/vary等头，由网关层强制设定proxy_cache_valid。
核心是切断重写对缓存键的干扰，让 Nginx 识别“逻辑相同但 URL 被改写”的请求为同一缓存项，同时避免因上下文混用导致状态错乱。
统一并锁定缓存键生成逻辑
重写（如 rewrite /api/v1/user → /backend/user）会改变 $request_uri，若 proxy_cache_key 依赖它，就可能把本应复用的请求打散成多个缓存条目。
- 改用稳定变量组合：用 $scheme$host$uri$is_args$args 替代 $request_uri —— $uri 是重写后的路径，$args 保留原始查询参数，二者组合能确保重写前后语义一致
- 禁用动态头参与 key：不加 $http_x_user_id、$cookie_token 等，除非业务明确需要用户级隔离；否则它们会随重写链路中代理头变化而抖动
- 若重写基于 header 或 cookie 做路由（如按 region 分流），可将关键维度提取为变量并纳入 key，例如 set $cache_context "$host|$arg_version|$http_x_region"; proxy_cache_key "$scheme$cache_context$uri$is_args$args";
隔离共享服务的缓存域与作用域
多个业务共用同一后端服务时，若所有 location 都指向同一个 keys_zone，重写后的不同路径可能命中彼此缓存，造成内容覆盖或状态污染。
- 按服务契约划分缓存区：为每个上游服务定义独立 proxy_cache_path 和 keys_zone，例如 proxy_cache_path /cache/auth keys_zone=auth_cache:64m; proxy_cache_path /cache/order keys_zone=order_cache:128m;
- 在重写 location 中显式绑定缓存区：location /api/v1/auth { rewrite ^/api/v1/auth/(.*)$ /$1 break; proxy_pass http://auth_upstream; proxy_cache auth_cache; }
- 禁止跨 service 复用缓存：即使路径相似（如 /v1/users 和 /v2/users），只要后端协议或版本不同，就绝不共用 keys_zone
控制响应头与缓存生命周期一致性
重写常伴随多层代理，容易叠加 X-Cache-Status、Vary 等头，或使 Cache-Control 被上游覆盖，导致缓存策略失效或头污染。
- 统一清理上游头：proxy_hide_header Cache-Control; proxy_hide_header Vary; proxy_hide_header ETag; —— 防止后端返回的 no-cache 或 vary:* 干扰本地缓存决策
- 由网关层主导缓存策略：proxy_cache_valid 200 201 302 5m; proxy_cache_valid 404 1m; 不依赖后端响应头，尤其对重写后接口要强制设定合理 TTL
- 禁用 proxy_cache_use_stale updating：该特性在重写频繁场景下易引发旧缓存未更新完成就被返回，造成数据短暂不一致
验证重写路径下的缓存行为是否收敛
不能只看配置是否生效，必须确认重写后的真实请求是否被正确归一化并命中预期缓存区。
- 用 curl -I 检查关键路径：对比重写前（/api/v1/user/123）和重写后（/backend/user/123）的 X-Cache-Status 是否都为 HIT，且值一致
- 查看缓存条目分布：nginx -T | grep "keys_zone" 确认各 zone 名称无误；再通过 stub_status 或自定义日志统计 auth_cache 中实际缓存条目数，避免“看似启用实则空转”
- 模拟并发压测：用 wrk 或 hey 对重写路径发起高并发请求，观察缓存命中率是否随 QPS 上升而稳定提升（而非波动剧烈），这是键收敛最直接的证据
