默认仅缓存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; - 对含认证头、表单提交、支付回调等路径，一律不缓存响应
