必须用 $upstream_http_content_type（proxy_pass 后填充，仅 http 块 map 可用），匹配需引号+大小写敏感（建议 ~* 忽略大小写），map 必须设 default；proxy_cache_valid 必须显式列状态码，如 200 302 $cache_ttl，不可省略；0s 表示不缓存；x-cache miss 常因 location 未启用 cache 或 key 冲突；调试用 add_header x-debug-content-type $cache_ttl。
map 怎么提取上游响应的 Content-Type
不能直接用 $http_content_type，那是请求头；必须用 $upstream_http_content_type，它在 proxy_pass 后才被填充，且只在 http 块中定义的 map 里可用。
- 匹配值是完整字符串，比如
"text/html"、"application/json"，注意引号和大小写（Nginx 默认区分，但建议统一小写 +~*忽略大小写） - 必须加
default，否则未匹配时变量为空，proxy_cache_valid会报错或退回到全局默认行为 - 正则要写在
default上方，否则永远走不到——比如想单独匹配 WebP，得写~*image/webp在default "1d"前面
proxy_cache_valid 能否直接引用 map 变量
可以，但有硬性限制：必须显式列出状态码，不能省略。写成 proxy_cache_valid 200 302 $cache_ttl 是合法的；写成 proxy_cache_valid $cache_ttl 会直接报配置错误。
-
"0s"表示“不缓存该响应”，不是“缓存 0 秒”——它会让 Nginx 跳过存储，但依然可能返回 200 - 若要强制回源（比如 API 请求），除了
proxy_cache_valid 200 302 0s，最好再加proxy_cache_bypass $cache_ttl，双重保险 - 缓存时间单位支持
s、m、h、d、y，但别用max或off，它们不被proxy_cache_valid接受
为什么缓存策略没生效，X-Cache 总是 MISS
常见原因不是 map 写错了，而是 location 没启用缓存或 key 冲突。
- 确认
proxy_cache指令已写在对应location里，且指向的keys_zone名字和proxy_cache_path一致 -
proxy_cache_key里如果包含$args，而上游返回的Content-Type实际由后端动态生成（比如 PHP 输出 JSON），那不同参数会导致缓存键分裂，命中率归零 - 用
curl -I http://your.site/api/user查看响应头：X-Cache是HIT还是MISS，Age是否递增，Cache-Control是否被覆盖
如何验证 map 变量是否按预期取值
最直接的办法是临时加一个调试响应头：add_header X-Debug-Content-Type $cache_ttl always，然后 curl 看返回值。
- 如果看到空值或
0s，说明map没匹配上——检查$upstream_http_content_type实际值（用add_header X-Upstream-CT $upstream_http_content_type always对比） - 如果看到值正确但缓存仍不生效，重点查
proxy_cache_valid的状态码列表是否覆盖了上游实际返回码（比如后端返回 201，但你只写了200 302） - 避免在
server或location中重复定义同名map变量，Nginx 不允许覆盖，会静默忽略后续定义
proxy_cache_valid 的状态码约束和 $upstream_http_content_type 的生命周期——它只在 proxy_pass 完成后存在，不能用于 rewrite 阶段，也不能在 if 块里引用。
