fastcgi_cache_min_uses 控制同一请求被重复访问多少次后才写入缓存，设为1则每次均尝试写入（默认但风险高），设为3则前两次不缓存、第三次起才写入；它只影响缓存写入时机，不影响请求转发与读取，需配合精准 cache_key、location 隔离及 inactive/use_stale 等策略协同调优。
fastcgi_cache_min_uses 不是独立生效的“开关”，而是缓存策略中控制“写入门槛”的关键一环——它决定同一个请求需被重复访问多少次后，Nginx 才将其响应真正写入缓存。设得过低（如默认 1），偶发调试、爬虫试探、后台探针等请求会直接污染缓存；设得过高又可能错过真实但初期流量不稳的热点接口。调优的核心在于匹配业务访问模式，而非追求单一数值。
明确作用边界：它只管“写”，不管“读”和“拦截”
该指令不影响请求是否转发给 PHP-FPM，也不阻止首次访问执行。它的逻辑很纯粹：
- 设为 1：每次命中都尝试写缓存（默认行为，风险高）
- 设为 3：前两次访问照常走后端、响应不缓存；第三次起，若仍命中同一 cache_key，才开始写入
- 已缓存的内容仍可正常返回，不受 min_uses 影响
必须配合 cache_key 和 location 做精准隔离
如果所有接口共用一个缓存 zone 且 key 粗粒度（比如只含 URI），那再高的 min_uses 也挡不住偶发请求“搭便车”。实际应分层控制：
- 对明确不缓存的接口（如
/api/v1/debug/、/healthz），直接在 location 中关闭：fastcgi_cache off; - 对需缓存的业务接口，key 中加入稳定标识，例如：
fastcgi_cache_key "$scheme$request_method$host$request_uri$args";（带参数）或通过$http_x_api_version等 header 进一步细分 - 避免把管理后台、用户私有接口与公开 API 混在同一 cache zone
协同 inactive 和 use_stale 构建防御闭环
即使偶发请求侥幸跨过 min_uses 阈值写入缓存，也要确保它不会长期滞留：
-
inactive=2m：2 分钟内无再次访问即标记为可回收，适合接口调用节奏快、冷热切换明显的场景 -
fastcgi_cache_use_stale error timeout http_500;：后端临时故障时仍可返回旧缓存，防止偶发失败触发大量回源，加剧雪崩 - 缓存路径建议独立分区，例如：
fastcgi_cache_path /www/server/nginx/fastcgi_api levels=1:2 keys_zone=API_CACHE:50m inactive=2m max_size=200m;
典型场景参考值
没有万能数字，但可按接口稳定性分级设置：
- 核心商品页、首页等强热点：min_uses 1～2（已足够稳定，早缓存早受益）
- 用户中心类接口（带 UID 参数）：min_uses 3～5（需观察是否真有重复访问模式）
- 后台任务轮询、监控探针：min_uses 10 或直接
fastcgi_cache off - 新上线接口灰度期：先设为 5，观察 access log 中相同 key 的 hit frequency，再下调
