fastcgi_cache_methods 是缓存方法的显式授权列表，非白名单机制；默认仅允许 GET 和 HEAD，扩展需谨慎，须结合 location、map、cache_bypass 等实现精细化控制，并确保 cache_key 唯一且忽略敏感字段，同时用 fastcgi_ignore_headers 覆盖后端禁缓存头。
fastcgi_cache_methods 本身不是“白名单”机制，它定义的是哪些 HTTP 方法的响应**允许被缓存**，本质是缓存方法的显式授权列表。所谓“缓存白名单”，实际是指通过组合 fastcgi_cache_methods 与其他指令（如 location 匹配、map 判断、cache_bypass 等），实现对特定请求路径、方法、参数或头部的精细化缓存控制。
明确启用可缓存的 HTTP 方法
该指令直接决定 Nginx 是否会对某类请求尝试缓存其 FastCGI 响应，默认仅允许 GET 和 HEAD：
-
安全默认值：不配置即等效于
fastcgi_cache_methods GET HEAD;，POST、PUT、DELETE 等一律不进入缓存，这是最稳妥的选择 -
扩展幂等方法：仅当后端接口语义只读且幂等（如 JSON 搜索、资源预热）时，才考虑加入 POST：
fastcgi_cache_methods GET HEAD POST; - 谨慎添加 PUT/DELETE：除非明确用于只读资源状态查询（极少见），否则不应加入；Nginx 不校验业务逻辑，加了不代表安全
用 location + map 实现路径与方法组合白名单
单靠 fastcgi_cache_methods 无法区分“哪些 POST 可缓存”，必须配合作用域控制：
- 将缓存配置限定在特定 location 中，例如只对
/api/search开放 POST 缓存：location ^~ /api/search { ... fastcgi_cache_methods GET HEAD POST; ... } - 用 map 构建动态缓存开关变量，按请求特征排除敏感操作：
map $request_method:$request_uri $no_cache { ~^(POST|PUT):/login 1; ~^POST:/order 1; default 0; }，再在 location 中写fastcgi_no_cache $no_cache; - 也可用 $arg_nocache 或 $cookie_admin 标识调试或管理请求，实现人工绕过：
fastcgi_cache_bypass $arg_nocache $cookie_admin;
确保缓存键唯一且不含敏感上下文
即使方法和路径被允许，若 cache_key 无法区分不同请求，仍会缓存污染——这相当于隐性“黑名单失效”：
- 避免使用
$request_body：Nginx 不保证其可用性，且含空格、换行、编码差异会导致 key 不一致 - 推荐方案：前端把查询参数转为 query string（改用 GET）；或后端计算参数哈希并注入
X-Request-Sign头，key 写成"$scheme$request_method$host$request_uri$upstream_http_x_request_sign" - 严禁包含用户标识字段：如
$cookie_sessionid、$remote_addr（除非做私有缓存），否则无法共享，失去缓存价值
强制覆盖后端不可缓存响应头
后端返回 Cache-Control: no-cache 或 Set-Cookie 时，Nginx 默认跳过缓存——需主动干预才能让白名单生效：
- 添加
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;，使 Nginx 忽略这些禁止缓存的响应头 - 配套设置有效缓存时间：
fastcgi_cache_valid 200 302 5m;，明确告诉 Nginx “只要状态码匹配，就缓存 5 分钟” - 验证是否生效：加
add_header X-Cache $upstream_cache_status;，响应头出现HIT才说明真正命中
