fastcgi_cache_methods 默认仅缓存 get/head 请求，post 不缓存；如需缓存 post，须同时满足幂等性、安全性、无敏感上下文，并配置 fastcgi_cache_methods get head post、忽略 cache-control 等头、设计唯一 cache_key 及配套指令。
fastcgi_cache_methods 决定哪些 HTTP 方法的响应可以被 Nginx 缓存，默认只允许 GET 和 HEAD，不缓存 POST（出于安全和语义考虑）。是否启用 POST 缓存，取决于你的业务是否真正符合「只读、幂等、无敏感上下文」这三条前提。
默认配置：仅缓存 GET/HEAD 是最安全的选择
绝大多数动态接口（如登录、提交表单、下单）不应缓存 POST 响应。Nginx 默认行为就是：
fastcgi_cache_methods GET HEAD;- 即使后端返回了
Cache-Control: public, max-age=60，POST 响应也不会进入缓存 - 无需额外干预，适合标准 PHP 网站、WordPress、Laravel 等常规应用
扩展支持 POST：必须同时满足三重条件
仅当接口是「查询类 POST」（例如 JSON 搜索 API），且你已确认其幂等性与安全性时，才可显式加入 POST：
- 在启用缓存的 location 块中写入：
fastcgi_cache_methods GET HEAD POST; - 必须配合
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;，否则后端返回的禁用缓存头会直接跳过缓存 - 必须确保
fastcgi_cache_key能唯一标识不同请求 —— 不能直接用$request_body（Nginx 不保证 body 可读或已解析），推荐改用带签名的 query string 或由后端注入X-Request-Sign头再参与 key 构造
缓存 key 设计直接影响 POST 缓存效果
key 错误会导致所有 POST 请求命中同一个缓存项，造成结果错乱。常见有效写法：
- 若前端能将参数转为 query（推荐）：
fastcgi_cache_key "$scheme$request_method$host$request_uri$is_args$args"; - 若必须用 POST body，需后端配合输出稳定标识：
fastcgi_cache_key "$scheme$request_method$host$request_uri$upstream_http_x_request_sign"; - 避免包含用户会话信息（如
$cookie_sessionid），否则无法共享缓存
配套指令不可遗漏
单独加 POST 不起作用，还需同步设置：
-
fastcgi_cache_valid 200 302 5m;—— 明确声明 POST 成功响应的缓存有效期 -
fastcgi_cache_lock off;或合理配置fastcgi_cache_lock_timeout—— 防止并发请求重复穿透到后端 -
fastcgi_cache_bypass $arg_nocache $cookie_nocache;—— 提供手动绕过缓存的调试入口
