nginx 默认不缓存 post 请求，仅当 api 满足只读、幂等、无用户上下文三前提时才可安全开启；需同步配置 fastcgi_cache_methods、fastcgi_ignore_headers、稳定 cache_key 和 fastcgi_cache_valid 四项指令。
默认情况下，fastcgi_cache_methods 只缓存 GET 和 HEAD 请求，对 API 的 POST/PUT 等方法不生效——这不是配置遗漏，而是 Nginx 的安全设计。是否缓存非 GET API，关键看它是否满足「只读、幂等、无用户上下文」三个硬性前提。
哪些 API 适合开启 POST 缓存
并非所有 POST 都能缓；只有语义上等价于“查询”的接口才合适，例如：
- JSON 格式搜索接口（参数固定、结果不依赖 session 或 cookie）
- 批量获取资源的 RPC 式调用（如
/api/v1/items?ids=1,2,3改为 POST + body 提交 ID 列表，但后端处理逻辑不变） - 前端为绕过 URL 长度限制而改用 POST 的纯读取请求
登录、下单、修改状态等写操作，绝对不能缓存其响应。
必须同步配置的四项关键指令
单独加 fastcgi_cache_methods GET HEAD POST 没用，以下四点缺一不可：
-
显式启用方法：在已启用
fastcgi_cache的 location 块中写入fastcgi_cache_methods GET HEAD POST; -
忽略禁用头：加上
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;，否则后端返回的Cache-Control: no-cache会直接跳过缓存 -
构造稳定 key：避免用
$request_body（Nginx 不保证可读），推荐方式：
— 若能转 query：用fastcgi_cache_key "$scheme$request_method$host$request_uri$is_args$args";
— 若必须用 body：由后端注入X-Request-Sign头，再写成fastcgi_cache_key "$scheme$request_method$host$request_uri$upstream_http_x_request_sign"; -
明确缓存有效期：如
fastcgi_cache_valid 200 5m;，POST 成功响应必须显式声明，否则不缓存
容易踩坑的细节
缓存错乱往往不是配置没写全，而是细节失控：
-
fastcgi_cache_key中混入$cookie_xxx或$sessionid→ 每个用户缓存一份，失去共享价值 - 未关掉
fastcgi_cache_lock或超时太短 → 高并发下大量请求穿透到后端 - location 匹配顺序错误，导致
fastcgi_no_cache或fastcgi_cache_bypass生效，覆盖了你的缓存设置 - PHP 脚本自身输出了
Set-Cookie头 → 即使加了fastcgi_ignore_headers，也建议后端主动清理该头
验证是否真正生效
加一行响应头便于调试：add_header X-Cache-Status $upstream_cache_status;。访问时检查响应头：
-
X-Cache-Status: HIT→ 缓存命中 -
X-Cache-Status: MISS→ 未命中（首次或 key 不匹配） -
X-Cache-Status: BYPASS→ 被fastcgi_cache_bypass或其他规则跳过 - 完全没这个头 → 缓存根本没启用，先检查
fastcgi_cache和fastcgi_pass是否在同个 location
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
