proxy_cache_min_uses 的核心作用是延迟缓存写入，仅在请求达到指定次数（如2次）后才将响应写入磁盘，从而过滤调试、爬虫、随机参数等低价值访问；需配合 proxy_cache_lock 和精简的 proxy_cache_key 才能生效。
proxy_cache_min_uses 的核心作用，是让 Nginx 对“偶发性访问”保持克制——不急着落盘，只在确认有真实复用价值后才写入缓存。它不拦截请求、不跳过回源，但能有效防止单次调试、爬虫试探、参数随机的埋点等低价值请求，把磁盘空间和 keys_zone 内存留给真正高频的内容。
静态资源路径设为 2～3，过滤一次性抓取
这类资源（.js、.css、.png、.woff2 等）天然具备复用性，但大量偶发访问来自：
- 构建工具预览时的单次加载
- 爬虫或监控系统的一轮扫描
- 前端开发者本地调试的临时请求
设 proxy_cache_min_uses 2 后：
- 第 1 次访问仍回源，响应不写盘
- 第 2 次同 URI 请求触发写入，后续全部 HIT
- 实测可减少 40%～60% 的无效小文件生成
配置示例：
location ~* \.(js|css|png|jpg|gif|webp|woff2?)$ {
proxy_cache static_cache;
proxy_cache_valid 200 1d;
proxy_cache_min_uses 2;
proxy_cache_lock on;
proxy_cache_lock_timeout 5s;
}动态接口按语义分层，避免一刀切
不是所有动态路径都适合统一设高值，需结合业务逻辑判断是否“真有复用可能”：
-
/api/config、/这类公共入口：保持min_uses 1，首次即缓存更合理 -
/api/article?id=123或/user/profile?uid=456：设为2或3，匹配用户真实回访节奏 -
/log?r=abc&t=1746216840这类带毫秒时间戳的上报：不依赖 min_uses，直接用proxy_no_cache 1或proxy_cache_bypass $arg_r $arg_t跳出缓存流程
必须启用 proxy_cache_lock，否则前几次请求仍会并发刷盘
仅设 min_uses 2 不够——若无锁机制，第 1 次和第 2 次请求可能同时回源、各自尝试写缓存（哪怕只有一次成功），IO 消耗翻倍。加锁后：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- 第 1 次请求回源 + 加锁
- 第 2 次请求等待锁释放，不重复发起后端请求
- 锁释放时统一写入一次，自然满足
min_uses=2条件
务必同步配置：
proxy_cache_lock on; proxy_cache_lock_timeout 5s;
精简 cache_key 是前提，否则 min_uses 形同虚设
如果 proxy_cache_key 包含 $args 或 $request_uri，那么 /log?t=1746216840&r=a 和 /log?t=1746216841&r=b 就是两个 key，永远达不到计数门槛。应显式剔除干扰字段：
proxy_cache_key "$scheme$host$uri$is_args$arg_id$arg_type";
对无法精简的路径（如含大量 utm 参数），可用 map 预处理：
map $args $skip_cache {
~utm_source= 1;
~r=[a-zA-Z0-9]+ 1;
default 0;
}
proxy_cache_bypass $skip_cache;
proxy_no_cache $skip_cache;上线后看效果，别只信配置
加了 min_uses 不代表就起效，要验证是否真在过滤偶发访问：
- 在 response header 中暴露状态：
add_header X-Cache-Status $upstream_cache_status; - 查日志中某类路径是否长期
MISS却从不转为HIT - 统计缓存目录新建小文件数：
find /var/cache/nginx -type f -mmin -30 | wc -l，对比调参前后变化 - 观察
inactive=60m下，大量缓存是否几秒内就被淘汰——那是典型的“写了一次就丢”
不复杂但容易忽略
