缓存键需精准反映共享缓存的请求条件，而非越长越好；应组合关键变量如$request_method、$host、哈希后$cookie_user_id等，并清洗无关参数，配合日志与响应头验证生效。
缓存键（proxy_cache_key 或 fastcgi_cache_key）不是“越长越好”，而是要精准反映“什么请求该共享同一份缓存”。构建不当，轻则命中率低，重则用户看到他人数据、移动端返回 PC 内容、带 token 的响应被公开缓存。
关键变量组合：按业务场景选配
默认的 $scheme$proxy_host$request_uri 忽略请求方法、头信息和 Cookie，多数生产环境需增强：
- 区分 GET/HEAD/POST 语义：加入
$request_method，避免 HEAD 请求意外命中并覆盖 GET 缓存 - 支持多子域或协议混用：用
$host替代$proxy_host，确保api.example.com和www.example.com不共用缓存 - 适配登录态或角色差异：添加
$cookie_user_id或$http_x_user_role（推荐哈希后使用，如md5($cookie_user_id)），避免敏感字段明文入 key - 兼容移动端判断：优先用
$http_x_requested_with（值为XMLHttpRequest或空）或自定义 header，比$http_user_agent更稳定、更轻量
过滤无关参数：减少缓存碎片
UTM 跟踪、时间戳、随机数等参数不改变内容逻辑，却会导致相同资源生成大量 key。直接拼接 $args 易引发膨胀，应预处理：
- 在
http块中定义map清洗参数串，例如剔除utm_*、ts=、random= - key 中使用清洗后的变量，如
proxy_cache_key "$scheme$host$request_uri$is_args$clean_args"; - 若后端对参数顺序不敏感（如
?a=1&b=2与?b=2&a=1等价），Nginx 原生不支持排序，建议只对明确需参数区分的路径启用缓存（如限定location ~ \.php$）
验证与调试：确认 key 按预期生成
配置写完不等于生效，必须验证 key 是否真实按设计输出：
- 添加日志格式：
log_format cache '$cache_key - $upstream_cache_status';，再在access_log中启用该格式 - 用
curl -I观察响应头中的X-Cache-Status（需配置add_header X-Cache-Status $upstream_cache_status;）和Age字段变化 - 临时设 key 为固定字符串（如
"debug_key"），观察多个不同请求是否全部命中HIT，可快速定位配置是否加载成功
配套前提：key 生效的三个必要条件
即使 key 写得再精确，缺以下任一环节，缓存也不会工作：
-
proxy_cache_path已在http块声明，路径存在且 Nginx 进程有读写权限（macOS 上注意/usr/local/var/cache/nginx的 owner/group） - 对应
location中启用了proxy_cache zone_name;并引用了上述keys_zone名称 - 后端响应含有效缓存控制头（如
Cache-Control: public, max-age=60），或 Nginx 侧用proxy_cache_valid强制缓存指定状态码
