proxy_cache_min_uses是缓存写入的“热度门槛”，决定URI响应第几次访问才落盘，旨在防止低频长尾请求占用缓存资源；需结合路径语义分层设置，并配合proxy_cache_lock避免重复回源。
proxy_cache_min_uses 不是请求过滤器，而是缓存写入的“热度门槛”——它不拦截请求、不跳过回源，只决定某个 URI 的响应体第几次访问才真正落盘到缓存中。配置它的核心目标，是防止大量单次访问、参数随机、路径试探类的“低频长尾”请求反复占用 keys_zone 内存和磁盘空间，从而保护缓存健康度。
识别真正的“长尾”请求特征
长尾请求不是“访问量少”，而是具备以下组合特征：
- URI 高度离散（如带时间戳
/log?t=1745428260&r=xyz、随机埋点 ID、爬虫扫描路径/wp-admin/） - 单个 URI 全生命周期仅被访问 1–2 次，却占总请求数 20% 以上
- 对应缓存 key 几乎从不复用，
$upstream_cache_status长期为MISS，且inactive时间内就被淘汰 - 日志中大量 404 或 204 响应，说明路径无效或接口无实际业务价值
按路径语义分层设置 min_uses 值
全局统一设值容易误伤，应结合资源类型与访问模式差异化配置：
-
静态资源（
/static/、.js/.css/.png）：设为2—— 过滤掉单次爬虫抓取或调试请求，保留真实用户二次加载行为 -
首页、公共 API（
/、/api/config）：保持1—— 本身复用率高，无需预热，首次即缓存更合理 -
带用户标识的页面（
/user/123、/order/abc）：设为2或3—— 匹配真实回访场景，避免冷启动后立即失效 -
含随机参数的上报接口（
/track?、/beacon?）：不用min_uses，直接用map或if跳过缓存模块：proxy_no_cache 1;或proxy_cache_bypass $arg_nocache;
必须搭配 proxy_cache_lock 才能避免重复回源
仅设 min_uses 2 会导致前两次请求都穿透回源，白白增加后端压力。加上锁机制后：
- 第 1 次请求触发回源并加锁
- 第 2 次同 URI 请求等待锁释放，不重复回源
- 锁释放后，响应写入缓存，第 2 次请求顺带返回结果
- 后续请求直接
HIT，实现“一次回源、多次服务”
配置示例：proxy_cache_lock on; proxy_cache_lock_timeout 5s;
验证是否生效的关键观测点
在 location 块中加入两行，用于线上观察：
add_header X-Cache-Status $upstream_cache_status;- 日志格式中记录
$upstream_cache_status字段
重点关注：MISS 是否集中在特定路径、是否持续不转为 HIT；对比调整前后 keys_zone 内存占用率与磁盘缓存条目增长速度。
