proxy_cache_min_uses需配合proxy_cache_lock和精简cache_key才能有效减少磁盘写入：设值2～3过滤低频请求，按路径分层配置，避免小文件碎片化，结合日志与监控验证效果。
直接设高值并不能延长磁盘寿命，关键在于让低频请求根本“不写盘”。proxy_cache_min_uses 的作用是延迟写入——只有达到指定次数的请求，响应体才真正落盘。它不拦截请求、不减少回源，但能有效避免大量只访问一次的 URL（如爬虫路径、带随机参数的埋点、错误 404 资源）反复生成小缓存文件，从而降低磁盘 IO 频次和碎片化写入。
按路径价值分层设置 min_uses
全局统一设值容易误伤或失效，应结合业务语义在 location 块中差异化配置：
- 静态资源（.js/.css/.png/.woff2）：设为 2～3 —— 过滤单次爬虫抓取和调试请求，保留真实用户二次加载行为
- 首页 HTML 或公共接口（如 /api/config）：保持 1 —— 天然高复用，无需预热，首次即缓存更合理
- 带用户标识的路径（如 /user/123、/api/order?uid=456）：设为 2～3 —— 匹配真实回访规律，避免单次访问就占缓存空间
- 含时间戳/随机串的上报接口（如 /log?t=1744624800&r=abc123）：不依赖 min_uses，改用 proxy_no_cache 1 或 proxy_cache_bypass $arg_t $arg_r 直接跳过缓存模块
必须搭配 proxy_cache_lock 才防重复刷盘
单独设 min_uses=2 只是“延后缓存”，若无锁机制，前两次同 URI 请求可能并发回源，导致两次响应都尝试写盘（即使第二次才正式落盘，IO 操作仍发生两次）。加上 lock 后：
- 第 1 次请求触发回源 + 加锁
- 第 2 次请求等待锁释放，不重复回源
- 锁释放后，响应写入缓存，第 2 次请求顺带返回结果 —— 此时自然满足 min_uses=2 条件
- 后续请求全部 HIT，磁盘仅写入一次
精简 cache_key 是前置条件
如果 proxy_cache_key 包含了易变字段（如 $args、$request_uri），那再高的 min_uses 也无效——每个带不同随机参数的请求都被视为新 key，永远达不到计数门槛。务必优化 key：
- 静态资源：用 $uri 或 $scheme$host$uri，排除查询参数
- API 接口：用 $scheme$host$uri$is_args$arg_uid 等可控参数，剔除 utm_source、_t、r 等干扰项
- 配合 map 指令预处理：例如将带非法参数的请求映射为 bypass 标志，再用 proxy_cache_bypass 控制
验证是否真正在减少磁盘写入
上线后不能只看配置，要观察实际行为：
- 开启日志记录：$upstream_cache_status，重点关注 MISS 状态是否大量出现且不转为 HIT
- 监控缓存目录：find /var/cache/nginx/my_cache -type f | wc -l 增速是否明显放缓
- 检查小文件堆积：find /var/cache/nginx/my_cache -size -4k -mtime -1 是否显著减少（这类文件多为长尾请求残留）
- 对比前后端 QPS：若后端请求数未明显上升，说明 min_uses + lock 组合生效；若后端压力反增，大概率是 min_uses 设得过高或漏配 lock
