proxy_cache_min_uses 是缓存写入的准入过滤器，非淘汰机制；它设热度门槛（如设为2则同一key需访问2次才落盘），从源头减少需被淘汰的缓存条目，真正的淘汰由inactive（如1h无访问自动清理）和max_size（如500m空间上限+lru清理）协同完成。

proxy_cache_min_uses 本身不实现缓存淘汰逻辑，它只控制“缓存写入”的准入门槛——即某个响应是否落盘。真正的淘汰由 inactive 和 max_size 驱动，min_uses 的作用是从源头减少需要被淘汰的对象数量。

---

它不是淘汰机制，而是“准入过滤器”

• proxy_cache_min_uses 2 意味着：同一 cache key 必须被请求 至少 2 次，Nginx 才会把响应体写入磁盘缓存；
• 第 1 次请求仍会回源、查缓存（可能 HIT 已有旧副本）、生成临时响应，但不落盘；
• 只有第 2 次（及之后）满足条件的请求，才触发正式缓存写入；
• 已写入的缓存项，后续是否保留，完全取决于 inactive（无访问自动清理）和 max_size（空间满时 LRU 清理）。

---

真正的淘汰靠这两项配合

• inactive=1h
  缓存项在 1 小时内没有任何一次命中（access），就会被自动删除；
  这对低频长尾请求特别有效——哪怕误入缓存，也很快释放空间。

• max_size=500m
  限制整个缓存目录占用的磁盘上限；
  超限时 Nginx 按 LRU（最近最少使用）策略清理冷数据，无需人工干预。

两者共同构成“生命周期管理”，而 min_uses 是前置守门员，不让低价值请求进这个生命周期。

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

---

为什么单靠 min_uses 不能替代淘汰？

• 它不清理已有缓存，只拦新条目；
• 它无法识别“已缓存但长期不用”的冷数据；
• 它是单机计数，不同 worker 或重启后计数清零，不具备全局热度统计能力；
• 若不配 inactive，即使设了 min_uses 5，一旦某 key 达到 5 次，它就会长期滞留，反而加重淘汰压力。

---

实际配置中必须协同生效

• 静态资源路径启用 min_uses 2 + inactive 1h + max_size 500m
• 首页或公共 API 保持 min_uses 1，但同样要设 inactive 24h 和合理 max_size
• 带随机参数的埋点接口，直接用 proxy_no_cache 1 绕过整个缓存流程，比依赖 min_uses 更彻底

不复杂但容易忽略