proxy_cache_min_uses 不是拦截请求，而是设热度门槛让冷数据不落盘；静态资源设为2并精简key（如"$scheme$host$uri"）、启用proxy_cache_lock on及inactive=30m、max_size=2g，可减少40%～60%无效小文件。
proxy_cache_min_uses 不是拦截冷数据请求，而是让冷数据“不落盘”——它通过设置热度门槛，只在确认有复用价值后才将响应写入缓存磁盘，从而从源头避免冷数据污染。
它解决的核心问题是：
大量只访问 1–2 次的低频请求（如爬虫试探、调试路径、带随机参数的埋点 /log?t=123&r=abc、CI 预览页、误输 URL）默认会立即生成缓存文件。这些 KB 级“僵尸文件”堆积在 SSD 上，挤占快照空间、加剧擦写损耗、拖慢备份节奏，还浪费 keys_zone 内存。
静态资源设为 2，过滤单次噪声
静态文件（.js .css .png .woff2 等）天然适合复用，但真实场景中常被单次抓取：
- 构建工具预览时请求
/app.js?v=build-001 - 爬虫扫描
/logo.png?ts=1746216840 - 开发者本地调试拼错路径
只需在精准匹配的 location 中配置：
location ~* \.(js|css|png|jpg|gif|webp|woff2?|ttf|svg)$ {
proxy_cache my_cache;
proxy_cache_min_uses 2;
proxy_cache_key "$scheme$host$uri"; # 彻底剔除 $args
}首次请求仍回源（可能 HIT 已有副本），但响应不写盘；第二次相同 URI 才正式缓存。实测可减少 40%～60% 的无效小文件。
必须启用 proxy_cache_lock，防并发刷盘
光设 min_uses 2 不够。若两个相同请求几乎同时到达：
- 都判定“未达阈值”，都绕过缓存 → 同时回源
- 都尝试写缓存 → IO 白耗、后端压力翻倍
加锁后变成：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 第一个请求回源 + 加锁
- 后续同 key 请求阻塞等待
- 锁释放时统一写入一次 → 自然满足“第 2 次”，磁盘仅写一次
务必同步配置：
proxy_cache_lock on; proxy_cache_lock_timeout 5s; # 略大于后端 P95 响应时间
cache_key 必须精简，否则 min_uses 失效
如果 proxy_cache_key 包含 $args 或 $request_uri，那么：
-
/logo.png?v=a和/logo.png?v=b就是两个 key - 计数永远归零，
min_uses形同虚设
正确做法是按语义提取稳定字段：
- 静态资源：
"$scheme$host$uri"（彻底排除所有参数） - 带业务参数的 API：
"$scheme$host$uri$is_args$arg_uid$arg_tid"（只保留必需参数） - 可配合
map预处理非法参数，再用proxy_cache_bypass跳过
inactive + max_size 控制冷数据生命周期
即使个别长尾请求误入缓存，也要防止滞留：
-
inactive=30m;：30 分钟内无访问即自动淘汰，避免冷数据堆积 -
max_size=2g;：限制磁盘总用量，触发 LRU 清理低频项 -
proxy_cache_use_stale updating;：后台更新时仍返回旧缓存，进一步降低写入压力
这些不是补救措施，而是与 min_uses 协同构成的闭环防护。
