缓存命中率低是因缓存键包含过多无关动态参数导致键碎片化；应通过日志分析定位扰动参数，用响应哈希比对验证参数必要性，再通过map预处理或简化proxy_cache_key收敛键。
缓存键里塞了太多动态参数，比如随机 token、埋点 ID、时间戳、User-Agent 甚至 Cookie，会导致同一资源生成大量不同 key，缓存条目爆炸式增长，命中率断崖下跌——这不是缓存没起作用，而是缓存被“打散”了。
看日志确认是不是键太碎
在 access_log 中加入 $upstream_cache_status 和 $request_uri，再加个 $args 或 $http_cookie（视情况而定），然后跑一段时间：
- 用 awk '{print $7,$12}' access.log | sort | uniq -c | sort -nr | head -20 查看最常出现的 URI + 状态组合，如果同一路径下 MISS 占比极高、且 args 差异极大（如 ?t=1718234567、?utm_source=weibo），基本就是 query 扰动
- 检查 HIT 条目是否高度分散：比如 /api/user?id=123 有 5 个 HIT，但每个对应不同 ?v=1.0.1 或 ?_r=abc123，说明这些参数进了 key 却不参与内容生成
验证哪些参数真影响响应
别猜，动手比对：
- 用 curl 对同一接口发两个请求：仅改动一个参数（如 ?utm_medium=email → ?utm_medium=wechat），其余头和 body 完全一致，用 sha256sum 算响应体哈希；若哈希相同，这个参数就不该进 key
- 重点排查：utm_*、ref、t、_（防缓存时间戳）、Sec-Fetch-*、Accept-Language（对纯 JSON 接口通常无效）
- 后端日志里查同一 $uri 下，$http_x_forwarded_for 或 $cookie_sessionid 变化时，响应是否真不同；若总是相同，就别让它搅局
收敛 key 的实操方法
目标是让语义相同的请求落到同一个 key 上：
- 用 map 预处理 $args，只保留业务必需的参数。例如只留 id、page、lang，其他全过滤掉
- 静态资源建议固定 key：proxy_cache_key "$uri";，忽略大小写和 query，再配 proxy_ignore_headers Cache-Control; 防后端干扰
- API 接口若无需用户隔离，去掉 $cookie_* 和 $http_user_agent；需要隔离的（如 /api/profile），只加稳定身份字段，比如 $cookie_token 或解析 JWT 后的 $jwt_sub
上线前快速验证效果
改完 key 别直接上生产，先做两件事：
- 临时把 key 改成极简版：proxy_cache_key "$scheme$host$uri";，观察命中率是否明显回升；若回升，说明原 key 确实太碎
- 用 curl -I 多次请求同一地址，看 X-Cache-Status 是否从连续 MISS 变成稳定 HIT，同时检查响应内容是否正确（避免误收窄导致混存）
