直接用 proxy_cache_key 控制缓存粒度更轻量可靠，它通过统一语义相同请求的缓存 key 规避多节点缓存不一致；key 应精准表达请求等价性，避免引入动态值，并配合 proxy_ignore_headers 和日志验证确保生效。
直接用 proxy_cache_key 控制缓存粒度，比在负载层做会话保持（sticky session）更轻量、更可靠。它不依赖客户端 IP 或 Cookie 分发逻辑，而是让相同语义的请求命中同一个缓存 key，自然规避了“请求被分到不同 Nginx 节点导致缓存不一致”的问题。
明确 cache_key 的设计目标
key 的本质是“请求等价性标识”——只要业务上认为两个请求该返回相同内容，它们的 key 就必须完全一致。
- 比如用户查询接口
/api/user?id=123和/api/user?id=456，业务上显然不该共用缓存，key 中保留$args是合理的 - 但若所有
/api/user请求都查同一份静态配置（如系统公告），那 key 就该强制统一为"$host:/api/user"，忽略参数和 header 差异 - 避免把
$http_x_user_id、$cookie_sessionid这类动态值写进 key，否则每个用户都会生成独立 key，缓存利用率归零
常用且安全的 key 模式
按场景选，不追求通用，只求精准覆盖：
-
全路径去参模式：适用于参数不影响响应内容的接口
proxy_cache_key "$scheme$host$request_uri";
自动剔除?a=1&b=2等 query 字符串，适合带跟踪参数的 H5 页面或埋点 URL -
固定路径模式：适用于纯静态资源或全局配置接口
proxy_cache_key "$host:/static/js/app.js";或"$host:/api/config"; -
主机+路径+关键参数模式：适用于需区分少数维度的接口
proxy_cache_key "$host:/api/product?category=$arg_category";
只保留业务强相关的参数，丢弃timestamp、sign等干扰项
配合 proxy_ignore_headers 防止 key 生效但缓存被跳过
即使 key 写对了，如果后端响应带 Set-Cookie 或 Vary: Cookie，Nginx 默认不缓存，等于 key 白设。
- 加这行让缓存不被响应头阻断：
proxy_ignore_headers Set-Cookie Vary; - 若必须保留某些 Vary 行为（如响应按语言区分），可改用
proxy_cache_key "$scheme$host$request_uri$http_accept_language";，把关键 Vary 值显式纳入 key
验证 key 是否真正生效
别只看配置有没有语法错误，要确认实际生成的 key 是否符合预期：
- 临时加日志：
log_format cache_log '$remote_addr - $upstream_cache_status "$request" "$cache_key"';
再在 location 中启用：access_log /var/log/nginx/cache.log cache_log; - 压测时观察 access log，检查相同业务请求是否打出完全一致的
$cache_key字符串 - 搭配
X-Cache-Status响应头（如HIT/MISS）交叉验证，确保高频请求确实复用缓存
