Nginx 内 fastcgi_cache_methods 处理特殊请求类型

默认仅缓存GET/HEAD请求；POST等非GET请求需同时满足只读性、幂等性、无敏感上下文及后端返回可缓存头才可缓存，且须配置fastcgi_cache_methods、fastcgi_ignore_headers、fastcgi_cache_valid、fastcgi_cache_lock及安全cache_key，并用map屏蔽敏感路径。

默认情况下，fastcgi_cache_methods 只允许缓存 GET 和 HEAD 请求。这是出于语义安全和幂等性考虑——绝大多数 POST、PUT、DELETE 等方法代表状态变更操作，不适合缓存。

哪些非 GET 请求可以考虑缓存

只有满足以下全部条件的请求才适合启用缓存：

• 语义上是只读的（例如搜索接口、数据聚合查询）
• 具有幂等性（相同参数多次提交返回完全一致的结果）
• 不依赖用户会话或敏感上下文（如登录态、临时 token）
• 后端明确返回可缓存响应头，如 Cache-Control: public, max-age=300

启用 POST 缓存的关键配置组合

单加 fastcgi_cache_methods GET HEAD POST 不起作用，必须同步配置：

• 在对应 location 块中写入：fastcgi_cache_methods GET HEAD POST;
• 禁用后端缓存控制头干扰：fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
• 设置有效缓存时间：fastcgi_cache_valid 200 302 5m;
• 确保缓存锁不阻塞：fastcgi_cache_lock off; 或合理配置超时

缓存键（cache_key）必须唯一且稳定

错误的 key 设计会导致所有 POST 请求命中同一缓存项，造成结果错乱：

• 避免直接使用 $request_body（Nginx 不保证其可用性或一致性）
• 推荐方式：前端将查询参数转为 query string，改用 GET；或由后端生成签名并写入 X-Request-Sign 头
• 示例 key：fastcgi_cache_key "$scheme$request_method$host$request_uri$upstream_http_x_request_sign";
• 严禁包含 $cookie_*、$sessionid 等用户级变量

务必排除高风险路径

即使全局启用了 POST 缓存，也要主动屏蔽敏感操作：

• 用 map 指令标记禁止缓存的路径或方法：map $request_uri $no_cache { ~^/(login|api/v1/order|user/profile) 1; }
• 在 location 中引用：fastcgi_no_cache $no_cache; 或 fastcgi_cache_bypass $no_cache;
• 对含认证头、表单提交、支付回调等路径，一律不缓存响应