proxy_cache_min_uses需分层配置：静态资源设2，首页/api设1，用户路径设2～3并精简key，上报接口禁用缓存；必须启用proxy_cache_lock防并发回源，并配inactive=30m和max_size=2g加速冷数据退出。
直接设高 proxy_cache_min_uses 不拦截请求，但能阻止低频路径的响应体写入磁盘——只有同一缓存 key 达到指定访问次数，内容才真正落盘。这对保护网关物理磁盘（尤其是用于快照备份的 SSD/NVMe 盘）至关重要：避免大量只访问一次的冷路径（如爬虫试探、调试接口、带随机参数的埋点）反复生成 KB 级“僵尸文件”，挤占快照空间、加剧碎片、加速擦写损耗。
按路径语义分层设值，不搞一刀切
全局统一设为 5 或 10 容易误伤中频内容，导致持续回源、快照空间没省下，后端压力反而上升。应在 location 块中差异化配置：
-
静态资源（.js/.css/.png/.woff2）：设为
2。过滤单次爬虫抓取、CI 预览、本地调试等噪声，保留真实用户二次加载价值 -
首页 HTML、公共 API 入口（如 /、/api/config）：保持
1。天然高复用，首次缓存即合理，早落盘更利于快照一致性 -
带用户标识路径（/user/123、/order?id=456）：设为
2～3，但必须先精简proxy_cache_key，剔除会话类、时间戳等干扰参数 -
含随机参数的上报接口（/log?t=xxx&r=yyy、/beacon）：不依赖
min_uses，改用proxy_no_cache 1或proxy_cache_bypass $arg_r $arg_t直接绕过整个缓存模块
必须配套 proxy_cache_lock，否则白设
单独调高 min_uses 只是“延后写”，不是“防写”。若无锁机制，前 N−1 次同 key 请求可能并发打到后端，各自触发临时响应处理，甚至引发部分索引更新或日志记录，徒增 SSD 写入压力。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 启用
proxy_cache_lock on，并设proxy_cache_lock_timeout 3s～5s（略大于后端 P95 响应时间） - 第 1 次请求回源 + 加锁；后续同 key 请求等待锁释放，不重复回源
- 锁释放时，响应统一写入一次缓存——此时自然满足
min_uses条件，磁盘仅写一次
精简 cache_key 是生效前提
若 proxy_cache_key 包含 $args 或 $request_uri，每个带不同随机参数的请求都被视为新 key，计数永远归零，min_uses 形同虚设。
- 静态资源建议用：
proxy_cache_key "$scheme$host$uri";（彻底排除查询参数） - API 接口建议用：
proxy_cache_key "$scheme$host$uri$is_args$arg_uid$arg_tid";（只保留业务必需参数） - 可配合
map指令预处理非法参数，再通过proxy_cache_bypass控制跳过
搭配 inactive 和 max_size 加速冷数据退出
即使少量长尾请求误入缓存，也要防止它们长期滞留、拖慢快照备份节奏：
-
inactive=30m;：30 分钟内无访问即自动淘汰，避免冷数据堆积 -
max_size=2g;：硬性限制缓存总容量，配合 LRU 自动清理低频项 - 若使用
use_temp_path=off（推荐），所有缓存直写proxy_cache_path目录，快照可直接对该目录做原子快照，无需担心临时文件残留
