proxy_cache_min_uses 是缓存热度准入门槛，只控制响应是否写入缓存，不影响缓存查找、请求转发、key计算及跨节点统计；需结合 proxy_cache_lock 与分层路径配置才能提升缓存效率。
proxy_cache_min_uses 不是缓存开关，而是“热度准入门槛”——它不阻止请求回源，但能拦住低频请求往缓存里塞垃圾数据。
它真正管什么、不管什么
该指令只控制“响应是否写入缓存”，对以下行为完全无影响：
- 是否检查缓存（哪怕设为 5，第 1 次请求仍会查 cache，命中就返回）
- 是否转发请求（所有请求照常发往后端，不会跳过或丢弃）
- 是否影响缓存查找逻辑或 key 计算方式
- 是否具备跨节点统计能力（纯单机计数，无法识别全局低频）
为什么长尾请求特别伤缓存效率
带随机参数的埋点接口（如 /log?uid=123&t=1713224400456&r=abc123）、爬虫试探路径（/wp-admin/、/phpmyadmin/）、单次调试请求，它们共同特点是：
- URI 高度离散，cache key 几乎不重复
- 单个 key 终身只被访问 1 次
- 却各自占用一份内存索引 + 磁盘空间（哪怕只有几 KB）
- 大量这类请求会快速填满
keys_zone内存区，挤占真正高频资源的 slot
分层配置才是关键：按路径价值定阈值
全局一刀切（比如全站设 min_uses 3）反而会误伤中频内容。应结合业务语义，在 location 块中差异化设置：
-
静态资源（js/css/img）：设为
2—— 过滤掉单次爬虫抓取，保留真实用户二次加载 -
首页 HTML 或公共 API（如 /api/config）：保持
1—— 本身复用率高，无需预热 -
带用户 ID 的页面（/user/123）：设为
2～3—— 匹配真实回访行为 -
含时间戳/随机串的上报接口：用
map或if显式跳过缓存模块，或设proxy_no_cache 1
搭配 proxy_cache_lock 才能发挥最大价值
单独设 min_uses 2 只是“延后缓存”，若不加锁，前两次请求可能并发回源，造成双倍压力。加上 proxy_cache_lock 后：
- 第 1 次请求触发回源，同时加锁
- 第 2 次同 URI 请求等待锁释放，不重复回源
- 锁释放后，响应写入缓存，第 2 次请求顺带拿到结果 —— 此时自然满足
min_uses=2条件 - 后续请求直接 HIT，实现“一次回源、多次服务”
验证是否生效的小技巧
在 location 中加入：add_header X-Cache-Status $upstream_cache_status;
配合日志记录 $upstream_cache_status 字段，观察实际命中状态变化：
-
MISS：未命中且本次未写入（可能因未达 min_uses） -
EXPIRED或STALE：命中但过期/陈旧，说明缓存已存在 -
HIT：成功从缓存返回 -
BYPASS：被proxy_no_cache或proxy_cache_bypass跳过
