关键是精准落地fastcgi_cache：只对语义只读、幂等、无敏感上下文的post启用缓存；用可靠cache_key（如x-request-sign）替代$request_body；忽略后端禁用头并显式设cache_valid；主动排除/admin|login等不可缓存路径。
核心是让缓存真正生效、稳定命中、安全绕过，而不是堆参数。动态请求吞吐量提升的关键，在于减少重复执行 PHP、降低后端压力、缩短首字节时间（TTFB），而这些都依赖 fastcgi_cache 的精准落地。
精准启用缓存方法，不盲目放开 POST
默认只缓存 GET/HEAD 是合理设计。只有确认某类 POST 接口满足全部条件时，才加进 fastcgi_cache_methods：
- 语义只读：比如
/api/search提交 JSON 查询，返回结果不随用户会话变化 - 幂等：相同请求体反复发送，响应完全一致
- 无敏感上下文：不携带 Cookie、Token、用户 ID 等私有字段
配置写在对应 location 内，避免全局污染：
fastcgi_cache_methods GET HEAD POST;构造可靠 cache_key，避开 $request_body 陷阱
Nginx 不保证 $request_body 在所有阶段都可用，尤其开启流式处理或后端提前读取 body 时，直接用它做 key 会导致缓存错乱、命中率暴跌。
更稳的替代方案：
- 前端把查询参数转成 query string，改用 GET —— 最简单、最兼容
- 后端解析 POST body 后生成唯一签名（如 SHA256），通过响应头传回：
X-Request-Sign: a1b2c3... - Nginx 中引用该头：fastcgi_cache_key "$scheme$request_method$host$request_uri$upstream_http_x_request_sign";
强制接管后端响应头，确保缓存可写入
即使启用了 POST 缓存，PHP 返回 Cache-Control: no-cache 或 Set-Cookie，Nginx 默认跳过缓存。必须显式忽略：
同时，必须配 fastcgi_cache_valid 明确声明有效期，否则 POST 响应不会被存入缓存：
fastcgi_cache_valid 200 302 5m;fastcgi_cache_valid 404 1m;
主动隔离不可缓存路径，防误击拖垮整体
登录页、后台接口、下单流程、用户中心等天然不适合缓存。不能只靠 fastcgi_cache_methods 控制，要主动排除：
- 用 location 匹配路径前缀，禁用缓存：location ~ ^/(admin|login|checkout|user/) { fastcgi_cache off; }
- 对需缓存的接口加白名单 location，单独配 key 和 valid 时间
- 配合 fastcgi_no_cache 和 fastcgi_cache_bypass 做运行时判断（如含特定 cookie 或参数时跳过）
