缓存是否命中取决于fastcgi_cache_key是否稳定、唯一且精准覆盖业务差异点；必须包含$args（如搜索页需区分参数），用map清洗utm_*等干扰参数，避免$cookie_*、$http_user_agent等破坏共享性的变量。
缓存是否命中，关键看 fastcgi_cache_key 是否稳定、唯一且覆盖业务真实差异点。它不是“越全越好”，而是要精准反映哪些变量真正影响响应内容——多一个无关变量，就多一份缓存碎片；少一个关键变量，就可能缓存污染或击穿。
必须包含 $args（尤其对搜索、分页类页面）
默认的 $scheme$request_method$host$request_uri 不含 query string，会导致 /search?s=nginx 和 /search?s=cache 被当成同一个 key，全部命中同一缓存。WordPress、ZBlogPHP 等 CMS 的搜索、分类归档页都依赖 $_GET 参数，必须显式加入：
fastcgi_cache_key "$scheme$request_method$host$request_uri$args";- 若后端已用
$request_uri（它天然包含 query string），也可直接用$request_uri，语义更简洁
需过滤干扰参数（如 utm_*、_ga、fbclid）
营销追踪参数不影响页面内容，却会让缓存 key 失控膨胀。不能靠 fastcgi_ignore_headers 处理，必须在 key 生成前清洗 $args：
- 用
map指令预处理（安全、高效、推荐）：
map $args $clean_args {
~^(utm_[^&]*|_ga|fbclid) "";
default $args;
}
再在 key 中使用：fastcgi_cache_key "$scheme$request_method$host$request_uri?$clean_args";
绝对避免引入会破坏共享性的变量
除非你明确要做登录态隔离或设备差异化缓存（如给移动端返回不同 HTML），否则以下变量绝不能出现在 key 中：
-
$cookie_*（如$cookie_wp_logged_in_*）——会让每个用户产生独立缓存，彻底丧失复用价值 -
$http_user_agent——不同浏览器、版本、爬虫都会生成不同 key，缓存利用率暴跌 -
$remote_addr或$http_x_forwarded_for——IP 维度缓存基本无意义，还易被滥用
注意 key 的稳定性与 Nginx 变量行为
某些变量在 FastCGI 上下文中行为不一致，比如 $query_string 在部分配置中可能为空，而 $request_uri 始终可靠：
- 优先选用
$request_uri（含原始 query string，解析稳定） - 避免在
server块中用if处理 key 逻辑——Nginx 官方明确提示其行为不可预测 - 测试时可用
add_header X-Cache-Key "$cache_key";输出实际生成的 key，验证是否符合预期
