fastcgi_cache_min_uses仅控制同一请求第几次命中才写入缓存，不决定缓存优先级或留存时长；设为1则每次尝试写入（默认但易污染），设为3则前两次不缓存、第三次起才写入；其价值在于过滤偶发请求，需配合精准cache_key、location隔离及inactive/use_stale等策略协同生效。
fastcgi_cache_min_uses 不设置缓存优先级，它只控制“同一个请求第几次命中才写入缓存”，和优先级无关。所谓“优先级”是常见误解——Nginx 没有按 min_uses 数值高低给缓存项打标签或排序，也不会因此让某些缓存更难被淘汰、更早被返回。
它真正干的事：设一个“写入门槛”
这个指令纯粹决定缓存写入的时机，逻辑很干净：
- 设为
1：每次请求响应都尝试写入（默认，但容易被调试、探针、爬虫污染） - 设为
3：前两次访问照常走后端、不缓存；第三次起，若仍匹配同一fastcgi_cache_key，才真正写入 - 已写入的缓存内容，无论 min_uses 是多少，都按
inactive和fastcgi_cache_valid规则管理生命周期
想影响“哪些缓存更容易保留”，得靠别的参数
真正决定缓存是否长期有效、是否容易被清理的，是以下配置：
-
inactive=5m：5 分钟内没再被访问，就标记为可回收；对轮询类接口可设成30s，对商品页可设成1h -
fastcgi_cache_valid 200 10m：明确告诉 Nginx，200 响应至少要存够 10 分钟，哪怕 inactive 时间到了也不马上删 -
fastcgi_cache_use_stale error timeout http_500：后端出问题时继续用旧缓存，避免因回源失败导致缓存提前失效
让“该缓存的”真正缓存起来，才是提升留存的关键
min_uses 的价值在于过滤掉那些偶然、非重复的请求，把缓存空间留给真实高频路径。比如：
- 首页、商品列表这类稳定接口，设
min_uses 2就够，冷启动快又防误写 - 带用户 ID 的订单查询，如果发现同一 URI+UID 组合每分钟稳定出现 20 次以上，才值得设
min_uses 3～5 - 健康检查
/healthz或调试接口/api/debug，直接在 location 里加fastcgi_cache off，彻底排除干扰
必须配合 cache_key 和隔离策略才生效
如果所有请求共用一个粗粒度 key（比如只含 $request_uri），那不同用户的请求会“挤”进同一个缓存槽——此时再调 min_uses 也没意义。正确做法是：
- 公开页面用：
fastcgi_cache_key "$scheme$request_method$host$request_uri$args"; - 需区分角色的 API，加入 header：
fastcgi_cache_key "$scheme$request_method$host$request_uri$args$http_x_role"; - 绝不把登录态接口和静态资源放在同一个
keys_zone里
