proxy_cache_min_uses 是缓存准入阈值，仅达指定访问次数的同一 key 才写入磁盘与共享内存；静态资源设为 2 可过滤试探请求，首页和公共接口保持 1，用户路径按回访规律设 2～3，带随机参数接口应绕过缓存，并需配合 proxy_cache_lock 防重复回源。
proxy_cache_min_uses 不是“筛选器”，它不判断内容优劣，也不淘汰已有缓存；它的作用很具体：只让达到指定访问次数的同一缓存 key，才把响应体真正写入磁盘和共享内存。所谓“优质缓存内容”，其实是业务中那些真实被复用、有稳定访问模式、值得长期保留的请求——而 min_uses 是帮 Nginx 识别并优先接纳这类内容的第一道准入门槛。
静态资源用 min_uses 2 过滤试探性访问
JS/CSS/图片/字体这类资源天然具备高复用性，但常被爬虫、CI 构建、前端调试等单次请求打穿：
-
/static/app.js?v=123（每次构建版本号变）→ 若$args在 cache_key 中，每个版本都算新 key，min_uses失效 - 正确做法：精简 key，例如用
$scheme$host$uri，排除查询参数 - 设为
2后，真实用户二次加载才会触发落盘，单次抓取或误点不占空间
首页和公共接口保持 min_uses 1
这类路径天然高频、语义稳定、无随机干扰：
-
location = /或location /api/config - 首次访问即缓存，避免冷启动延迟，也无需“预热”过程
- 不设更高值，否则会人为制造首次命中空档，增加后端瞬时压力
用户专属路径按回访规律设 2～3
如 /user/123、/order/abc，需匹配真实行为而非一刀切：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 新用户首访后，若 24 小时内有回访，说明有留存价值 →
min_uses 2合理 - 必须剔除会话类干扰参数（如
?token=xxx、&t=1744624800），否则计数无法累积 - 可配合
map提前识别无效参数，用proxy_cache_bypass直接跳过
带随机参数的接口不该依赖 min_uses
像 /log?r=abc&t=1744624800、/track?uid=xyz&ts=... 这类请求：
- URI 高度离散，cache key 几乎不重复，
min_uses形同虚设 - 正确做法：用
proxy_no_cache 1或proxy_cache_bypass $arg_r $arg_t显式绕过整个缓存流程 - 避免 keys_zone 内存被大量低价值 key 占满，挤占真正高频资源的空间
必须搭配 proxy_cache_lock on 才防重复写入
只调高 min_uses 而不加锁，会导致并发请求反复回源：
- 第一次请求回源 + 加锁
- 后续同 key 请求等待锁释放，不重复发往后端
- 锁释放时统一写入一次缓存 → 自然满足
min_uses=2条件 - 推荐
proxy_cache_lock_timeout 5s，略大于后端 P95 响应时间
验证是否生效，看响应头 X-Cache-Status：
- 连续两次相同请求，应依次出现
MISS（未达阈值）、MISS（等待锁后写入） - 第三次起稳定返回
HIT，且缓存目录下对应文件只新增一个
不复杂但容易忽略
