fastcgi_cache_min_uses决定同一请求第几次才写入缓存，仅影响缓存写入时机，不控制转发、读取或过期；需配合精准fastcgi_cache_key和location隔离使用，并结合inactive与use_stale构建完整缓存策略。
fastcgi_cache_min_uses 不是缓存“开关”，而是决定“第几次才写入缓存”的门槛值。它只影响缓存写入时机，不控制请求是否转发、不干预缓存读取，也不能延长缓存留存时间。
它到底怎么工作？
该指令配合 fastcgi_cache_key 判断“同一个请求”：只有当同一 cache_key 被连续命中指定次数后，Nginx 才将响应写入缓存。
- 设为 1：每次访问都尝试写缓存（默认行为，但易被调试、探针、爬虫污染）
- 设为 3：前两次走后端、响应不缓存；第三次起，若仍命中相同 key，才开始写入
- 已缓存的内容照常返回，不受 min_uses 影响——它管“进”，不管“出”或“用”
单独设数字没用，必须配合 key 和 location 隔离
如果所有接口共用一个缓存区，且 cache_key 过于粗略（比如只含 $request_uri），那不同用户、不同参数的请求会“搭便车”写入同一缓存项，min_uses 再高也无效。
- 对明确不缓存的路径（如
/api/v1/debug/、/healthz），直接在 location 中加fastcgi_cache off; - 需缓存的接口，key 应包含稳定区分维度：带完整参数
"$scheme$request_method$host$request_uri$args"，或加入$http_x_api_version等 header - 避免把用户私有接口（含 Cookie）、管理后台和公开 API 混在同一 cache zone
结合 inactive 和 use_stale 构建防御闭环
min_uses 控制谁“有资格进”，而 inactive 和 use_stale 才决定它“能留多久、出问题还靠不靠谱”。
-
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 或 token 参数）：min_uses 设为 3～5（观察是否真有重复访问规律）
- 秒级轮询类 API：可设为 1，但必须配
inactive=30s快速淘汰 - 后台探针、调试接口：直接
fastcgi_cache off，不参与缓存逻辑
