fastcgi_cache_min_uses用于设定同一缓存key需被命中指定次数后才首次写入缓存，旨在过滤低频偶发请求而非零访问；设为1易致调试、探针等请求污染缓存，建议按接口类型设为2–3并配合精准cache_key、inactive和use_stale协同调优。
fastcgi_cache_min_uses 并不用于“过滤零访问数据”——它根本不会处理零访问的情况，因为零访问的请求压根不会触发缓存写入逻辑。
它的作用是：设定一个访问次数阈值，只有当同一缓存 key 被请求达到指定次数后，Nginx 才将该响应写入 fastcgi_cache。换句话说，它过滤的是“低频、偶发、试探性”的请求，而非“零访问”。
真正与“零访问”相关的机制，其实是 inactive 参数和缓存清理行为，而不是 min_uses。
fastcgi_cache_min_uses 的真实作用
- 它只在响应被成功返回（状态码符合
fastcgi_cache_valid规则）且尚未缓存时起效； - 每次命中但未缓存的请求，会累加该 key 的计数器；
- 直到计数 ≥
min_uses，才首次写入缓存； - 一旦写入，后续请求直接走缓存，不再计数。
所以它本质是延迟缓存写入，不是过滤“没访问”，而是避免“刚访问就缓存”。
为什么设为 1 会带来问题
- 健康检查探针、浏览器预加载、爬虫抓取、调试请求等，常以单次或极低频方式访问；
- 若
min_uses=1，这些请求会立刻写入缓存，占用空间，还可能因响应含私有内容（如 Set-Cookie）导致缓存污染； - 更糟的是，若后端此时返回临时错误或不一致数据，错误响应也被缓存，影响后续用户。
如何合理设置 min_uses 来提升缓存质量
-
默认值 1 不适合生产环境，建议按业务节奏调整：
- 静态公开接口（如公告、区服列表）：设为 2 或 3，前几次走后端校验一致性，第 3 次起缓存；
- 秒级轮询类接口（如心跳、状态轮询）：可设为 1，但必须搭配短
inactive（如30s）快速回收； - 后台管理、用户专属接口：直接用
fastcgi_cache off或fastcgi_no_cache排除，不参与缓存；
- 配合
map指令精准控制哪些 URI 参与缓存判断，避免兜底规则误伤。
真正清理“零访问”缓存项靠的是 inactive
-
inactive=5m表示：某缓存项连续 5 分钟没被任何请求命中，就会被标记为可回收； - 清理由 Nginx 后台线程异步执行，不阻塞请求；
- 这才是应对“写入后长期无人访问”的核心机制；
-
min_uses和inactive是上下游关系：前者决定“谁进”，后者决定“谁出”。
配套关键配置不能漏
-
fastcgi_cache_key必须带足够区分维度（如$request_uri$args、$http_user_agent或角色 header），否则不同用户的请求共用一个 key，min_uses再准也无意义； -
fastcgi_cache_use_stale应启用（如error timeout http_500），保证后端短暂不可用时仍可用旧缓存，维持命中率； - 后端响应头需干净：不含
Cache-Control: no-cache、Set-Cookie、Vary: *等禁用缓存的字段，否则min_uses完全失效。
不复杂但容易忽略。
