应设proxy_cache_min_uses为热度门槛，只复用价值高请求才缓存；按路径分层配置：静态资源设2、首页/公共接口设1、用户路径精简key后设2或3、上报接口直接绕过缓存；必须启用proxy_cache_lock防并发刷盘；精简cache_key剔除干扰参数；配合inactive与max_size控制生命周期。
要避免偶发性低频请求污染全局缓存系统，核心不是堵住请求，而是让它们“不落盘”——proxy_cache_min_uses 的作用就是设一道热度门槛，只在确认有复用价值后才写入缓存。它不拦截、不跳过回源，但能从源头减少无效文件生成，保护 keys_zone 内存和磁盘空间。
按路径语义分层配置，拒绝一刀切
全局统一设值容易误伤高频内容，也放行中频噪声。应在 location 块中差异化控制：
-
静态资源（.js/.css/.png/.woff2 等）：设为
proxy_cache_min_uses 2。真实用户二次加载概率高，可过滤掉构建预览、爬虫扫描、本地调试等单次访问 -
首页、公共接口（/、/api/config）：保持
1。天然高复用，首次缓存即合理 -
带用户标识的路径（/user/123、/order?id=456）：设为
2或3，但必须先精简proxy_cache_key，剔除会话类干扰参数 -
含随机参数的上报接口（/log?、/track?、/beacon?）：不依赖 min_uses，直接用
proxy_no_cache 1或proxy_cache_bypass $arg_r $arg_t绕过整个缓存流程
必须启用 proxy_cache_lock，否则前几次请求仍会并发刷盘
仅设 min_uses 2 不够——若无锁机制，第 1 次和第 2 次请求可能同时回源、各自尝试写缓存，IO 消耗翻倍。加锁后才能实现“一次回源、一次写入、多次服务”：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_cache_lock on;：首个请求触发回源并加锁 -
proxy_cache_lock_timeout 5s;：避免等待过久，略大于后端平均响应时间即可 - 第二个请求阻塞等待，锁释放时统一写入，自然满足 min_uses 条件
精简 cache_key 是前提，否则 min_uses 形同虚设
如果 proxy_cache_key 包含 $args 或 $request_uri，那么 /logo.png?v=abc 和 /logo.png?v=def 就是两个 key，永远达不到计数门槛。应主动剔除干扰参数：
- 推荐写法：
proxy_cache_key "$scheme$request_method$host$uri"; - 更稳妥写法：
proxy_cache_key "$scheme$request_method$host$uri$is_args";（彻底排除所有查询参数） - 对带版本号或调试参数的资源，可用
proxy_cache_bypass $arg_debug $arg_v直接跳过缓存判断
配合 inactive 与 max_size 控制生命周期，防止冷数据滞留
即使少量长尾请求误入缓存，也要防止它们长期占位：
-
inactive=1h;：1 小时内无访问即自动淘汰，避免冷数据堆积 -
max_size=500m;：限制磁盘总用量，配合 LRU 自动清理低频项 - 加一行
proxy_cache_use_stale updating;：后台更新时仍可返回旧缓存，进一步降低写入压力
