Nginx 中 fastcgi_cache_min_uses 设置缓存优先级

fastcgi_cache_min_uses仅控制同一请求第几次命中才写入缓存，不决定缓存优先级或留存时长；设为1则每次尝试写入（默认但易污染），设为3则前两次不缓存、第三次起才写入；其价值在于过滤偶发请求，需配合精准cache_key、location隔离及inactive/use_stale等策略协同生效。

fastcgi_cache_min_uses 不设置缓存优先级，它只控制“同一个请求第几次命中才写入缓存”，和优先级无关。所谓“优先级”是常见误解——Nginx 没有按 min_uses 数值高低给缓存项打标签或排序，也不会因此让某些缓存更难被淘汰、更早被返回。

它真正干的事：设一个“写入门槛”

这个指令纯粹决定缓存写入的时机，逻辑很干净：

1. 设为 1：每次请求响应都尝试写入（默认，但容易被调试、探针、爬虫污染）
2. 设为 3：前两次访问照常走后端、不缓存；第三次起，若仍匹配同一 fastcgi_cache_key，才真正写入
3. 已写入的缓存内容，无论 min_uses 是多少，都按 inactive 和 fastcgi_cache_valid 规则管理生命周期

想影响“哪些缓存更容易保留”，得靠别的参数

真正决定缓存是否长期有效、是否容易被清理的，是以下配置：

1. inactive=5m：5 分钟内没再被访问，就标记为可回收；对轮询类接口可设成 30s，对商品页可设成 1h
2. fastcgi_cache_valid 200 10m：明确告诉 Nginx，200 响应至少要存够 10 分钟，哪怕 inactive 时间到了也不马上删
3. fastcgi_cache_use_stale error timeout http_500：后端出问题时继续用旧缓存，避免因回源失败导致缓存提前失效

让“该缓存的”真正缓存起来，才是提升留存的关键

min_uses 的价值在于过滤掉那些偶然、非重复的请求，把缓存空间留给真实高频路径。比如：

1. 首页、商品列表这类稳定接口，设 min_uses 2 就够，冷启动快又防误写
2. 带用户 ID 的订单查询，如果发现同一 URI+UID 组合每分钟稳定出现 20 次以上，才值得设 min_uses 3～5
3. 健康检查 /healthz 或调试接口 /api/debug，直接在 location 里加 fastcgi_cache off，彻底排除干扰

必须配合 cache_key 和隔离策略才生效

如果所有请求共用一个粗粒度 key（比如只含 $request_uri），那不同用户的请求会“挤”进同一个缓存槽——此时再调 min_uses 也没意义。正确做法是：

1. 公开页面用：fastcgi_cache_key "$scheme$request_method$host$request_uri$args";
2. 需区分角色的 API，加入 header：fastcgi_cache_key "$scheme$request_method$host$request_uri$args$http_x_role";
3. 绝不把登录态接口和静态资源放在同一个 keys_zone 里