proxy_cache_min_uses 真正控制的是“响应体是否写入磁盘缓存”的准入时机，即同一 URI（按 proxy_cache_key 计算）需被请求 n 次且均未命中时，才在第 n 次响应时落盘；它不阻断请求、不干预回源与缓存查找，仅约束新缓存创建。
什么是 proxy_cache_min_uses 真正控制的行为
proxy_cache_min_uses 不是“缓存阈值”，而是“缓存准入门槛”：它要求一个请求路径（由 proxy_cache_key 决定）**至少被发起 n 次**，且每次都是未命中（即上游返回 200/301/302 等可缓存状态），才会在第 n 次响应时真正写入磁盘缓存。
关键点在于：前 n−1 次请求全部绕过磁盘写入（但可能仍走内存缓存或直接透传），不生成缓存文件。这对长尾 URL（如带随机参数的埋点、调试接口、错误构造的资源路径）非常有效——它们几乎永远不会达到 min_uses，自然不会污染 proxy_cache_path 指定的磁盘目录。
常见误判：
– 设为 1 并不能“开启缓存”，它只是退化为传统即时缓存，长尾请求照常落盘；
– 它对已存在的缓存文件无影响，只约束新缓存的创建；
– 不影响 proxy_cache_valid 的过期逻辑，仅干预“是否首次写入”。
如何判断当前值是否正在放大磁盘侵蚀
直接观察缓存目录下文件数量与请求分布的错配程度。当出现以下现象，说明 proxy_cache_min_uses 过低（甚至为 1）：
-
find /var/cache/nginx/my_cache -type f | wc -l持续增长，但du -sh /var/cache/nginx/my_cache中大量小文件（ -
nginx -T | grep proxy_cache_key显示 key 包含了易变字段（如$args、$request_uri而非$uri） - 访问日志中存在高频 404 或 502 请求，但这些路径仍在生成缓存文件（可通过
tail -f /var/log/nginx/access.log | grep " 404 "+ 同步查缓存目录 mtime 验证）
此时应立刻检查 proxy_cache_min_uses 是否被设为 1 或未显式声明（默认即 1）。
设多少才合理：从流量特征反推数值
不是拍脑袋定数字，而是根据业务请求的重复性来设定。核心原则：**只缓存那些有真实复用价值的请求**。
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
建议按场景分级：
- 静态资源（JS/CSS/图片）：设
2即可。首屏加载一次，后续预加载或刷新再触发第二次，足够建立缓存 - API 接口（尤其带用户 ID 或分页参数）：必须结合
proxy_cache_key收敛。若 key 已剔除$args，设3~5更安全；若无法收敛 key，宁可设为10甚至关闭该 location 的缓存 - 埋点、心跳、调试接口：应在对应
location块中显式关闭缓存：proxy_cache off;，而非依赖min_uses抵御——因为它们本就不该进缓存流程
性能提示：设为 5 不会增加延迟，Nginx 仅在响应头写入后做一次计数器自增（in-memory counter），不涉及磁盘 I/O。
必须同步调整的配套配置
proxy_cache_min_uses 单独生效是危险的。它必须和以下三项配合使用，否则可能引发语义混乱或缓存污染：
-
proxy_cache_key $scheme$host$uri：强制剥离$args和$request_uri，否则不同参数的请求会被视为不同 key，永远达不到min_uses -
proxy_cache_lock on;：避免同一 key 在未缓存期间被多个并发请求反复打到上游（即“缓存雪崩前置”） -
proxy_cache_use_stale updating;：当后台正在更新缓存时，允许 Nginx 返回旧缓存，防止因min_uses导致的“空窗期”直接透传压力
特别注意：proxy_cache_lock_timeout 应略大于后端平均响应时间，否则锁失效会导致重复回源，抵消 min_uses 的节流效果。
磁盘侵蚀最顽固的地方，往往不是大文件堆积，而是成千上万个 32 字节的缓存元数据文件——它们不占多少空间，却耗尽 inode，让 df -i 先于 df -h 报警。调这个参数时，盯着 df -i 比盯着 du 更重要。
