proxy_cache_min_uses 的作用是延迟写入——仅同一缓存 key 达到指定访问次数才落盘，不拦截请求也不减少回源，但能避免低频 url（如带随机参数的埋点、爬虫路径）反复生成小文件，从而降低磁盘占用和碎片化；需分层配置、配合 proxy_cache_lock 和精简 cache_key 才生效。
直接设高值不能节省磁盘空间，关键在于让低频请求压根不生成缓存文件——proxy_cache_min_uses 的作用是延迟写入：只有达到指定访问次数的同一缓存 key，响应体才真正落盘。它不拦截请求、不减少回源，但能有效避免大量只访问一次的 URL（如带随机参数的埋点、爬虫扫描路径、404 资源）反复创建小文件，从而降低磁盘占用和碎片化。
按路径语义分层设置 min_uses 值
全局统一设值容易误伤高频内容或放行中频噪声，应结合资源类型与访问规律在 location 块中差异化配置：
-
静态资源（.js/.css/.png/.woff2）：设为
2或3。真实用户二次加载概率高，可过滤掉约 60% 的爬虫试探、CI 构建预览、前端调试请求 -
首页 HTML、公共接口（/、/api/config）：保持
1。天然高复用，首次缓存即有价值，无需预热 -
用户专属路径（/user/123、/order/abc）：设为
2。匹配真实回访行为，避免单次访问就占缓存空间又很快失效 -
含时间戳/随机串的上报接口（/log?ts=xxx&r=yyy）：不依赖 min_uses，改用
proxy_no_cache 1或proxy_cache_bypass $arg_r $arg_ts直接跳过缓存模块
必须搭配 proxy_cache_lock 防止重复写入
只设 proxy_cache_min_uses 2 不够——前两次请求若并发，会各自回源、各自尝试写缓存（即使第二次才正式落盘），IO 操作仍发生两次。启用锁后才能实现“一次写、多次读”：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 第 1 次请求触发回源 + 加锁
- 第 2 次同 key 请求等待锁释放，不重复回源
- 锁释放时，响应写入缓存，第 2 次请求顺带返回结果 → 自然满足 min_uses=2
- 后续请求全部 HIT，磁盘仅写入一次
配置示例：proxy_cache_lock on; proxy_cache_lock_timeout 5s;
精简 cache_key 是生效前提
如果 proxy_cache_key 包含易变字段（如 $args、$request_uri、$cookie_sessionid），每个带不同参数的请求都会被视为新 key，计数永远无法累积，min_uses 形同虚设：
- 静态资源建议用
$scheme$host$uri，排除查询参数 - API 接口建议用
$scheme$host$uri$is_args$arg_uid等可控参数，剔除utm_source、_t、r等干扰项 - 可用
map预处理：例如将含非法参数的请求映射为 bypass 标志，再通过proxy_cache_bypass控制
验证是否真在减少磁盘占用
上线后要观察实际行为，不能只看配置是否生效：
- 加响应头：
add_header X-Cache-Status $upstream_cache_status;，重点关注某类路径是否长期为MISS且从不转为HIT - 查日志：
$upstream_cache_status字段统计中，若大量MISS无后续EXPIRED或STALE，说明请求未达阈值、压根没写入 - 监控缓存目录：
find /var/cache/nginx/my_cache -type f -mmin -60 | wc -l统计 1 小时内新建文件数，对比调参前后变化 - 观察 keys_zone 内存占用率是否更稳定，避免被长尾 key 占满
