proxy_cache_min_uses控制响应写入缓存的触发次数，设为2表示第二次响应才写入缓存，影响索引占用与磁盘io，但不减少回源次数；需配合proxy_cache_lock防并发回源。
它不拦截请求，只延迟缓存写入——设为 2 并不能减少回源次数，但能避免低频响应反复刷盘。
proxy_cache_min_uses 到底控制什么
这个指令只决定「第几次响应才写入缓存」，不影响任何其他行为。默认 proxy_cache_min_uses 1，意味着第一次响应就落盘；设为 2，则前一次响应不存，第二次才写入并服务后续请求；设为 3，前两次都不存，第三次起才缓存。
✅ 它影响：keys_zone 内存索引占用、磁盘写入频次、长期缓存命中率
❌ 它不管：请求是否发往后端（所有请求照常回源）、是否读取已有缓存（已缓存项仍可 HIT）、proxy_cache_key 计算逻辑、CDN 层行为
为什么设高了反而加重后端压力
盲目全局提升 proxy_cache_min_uses（比如统一设成 5）会让大量中频请求（日均访问 2–4 次）永远卡在阈值外：它们既无法被缓存，又持续穿透回源——结果是磁盘 IO 没省下，后端 QPS 和延迟反而上升。
- 静态资源（
.js/.css/.png）适合设为2～3：过滤爬虫试探、单次调试等噪声 - 首页 HTML 或公共 JS 包这类强复用内容，保持
1更合理 - 带时间戳或随机参数的埋点接口（如
/log?ts=1744624800&r=abc123），应直接用proxy_no_cache 1或proxy_cache_bypass跳过缓存模块，而非依赖min_uses过滤
必须配合 proxy_cache_lock 才能避免重复回源
单独设 proxy_cache_min_uses 2 只是“延后缓存”，若无锁机制，前两次同 URI 请求可能并发回源，造成双倍压力。加上 proxy_cache_lock on 后：
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 第 1 次请求触发回源，同时加锁
- 第 2 次同 URI 请求等待锁释放，不重复回源
- 锁释放后，响应写入缓存，第 2 次请求顺带拿到结果 —— 此时自然满足
min_uses=2条件 - 后续请求直接
HIT，实现“一次回源、多次服务”
漏掉 proxy_cache_lock 是最常被忽略的实操坑：你以为在控缓存，实际在放大后端压力。
如何验证策略是否生效
在 location 块中加这一行，实时观察行为：add_header X-Cache-Status $upstream_cache_status;
配合 access log 记录 $upstream_cache_status 字段，重点关注：
• MISS：未命中且本次未写入（可能因未达 min_uses）
• HIT：成功从缓存返回
• EXPIRED/STALE：命中但过期/陈旧，说明缓存已存在
真正难调的是「局部热度」——同一 URI 在单机上访问 2 次可能达标，但在集群里分散到 3 台 Nginx 上，每台都只见到 1 次。它没有跨节点统计能力，这点必须心里有数。
