直接设高 proxy_cache_min_uses 不拦截请求，但只让达指定次数的缓存 key 落盘，从源头减少小文件堆积、磁盘碎片和 ssd 擦写损耗；需结合 key 精简、cache_lock、inactive/max_size 才生效。
直接设高 proxy_cache_min_uses 不会“拦截请求”，但它能有效阻止低频冷门数据写入磁盘——只有同一缓存 key 达到指定访问次数，响应体才真正落盘。这从源头减少无效文件生成，避免小文件堆积、磁盘碎片化和 SSD 擦写损耗。
识别真正该拦的冷门数据
不是访问少就要拦，关键是找那些“高频出现 + 单次写入 + 零复用”的请求：
-
URI 高度离散：比如
/log?t=1744624800&r=abc123、/wp-login.php、带 UUID 的调试路径、含时间戳的埋点接口 - 日志中大量 MISS，却几乎不转为 HIT 或 EXPIRED：说明响应写进去了，但再没人读
- 缓存目录下 KB 级小文件数量激增，但总容量增长缓慢：典型“写一次就丢”的僵尸文件
- 大量 404/204/302 响应出现在缓存路径中：非 200/301 类响应本就不该占空间
按路径类型分层设置 min_uses 值
一刀切设成 5 或 10 容易误伤真实中频内容。应结合语义，在 location 块中差异化配置：
-
静态资源（.js/.css/.png/.woff2）：设为
2。过滤爬虫单次抓取、CI 预览、调试误请求，保留用户二次加载价值 -
首页 HTML、公共 API（如 /、/api/config）：保持
1。天然高复用，首次缓存即合理 -
带用户标识路径（/user/123、/order?id=456）：设为
2或3，但必须先精简proxy_cache_key，剔除会话类干扰参数 -
含随机参数的上报接口（/track、/beacon、/log）：不靠
min_uses，改用proxy_no_cache 1或proxy_cache_bypass $arg_r $arg_t直接绕过整个缓存模块
必须配套的关键动作
单独调高 min_uses 效果有限，甚至引发重复回源和写放大。以下三项必须同步启用：
-
精简
proxy_cache_key：剔除易变字段，例如用$scheme$host$uri替代$request_uri，用$arg_uid替代$args；否则每个参数微调都算新 key，计数永远归零 -
启用
proxy_cache_lock on：防止前 N−1 次同 key 请求并发打到后端。第一次回源加锁，后续请求等待，锁释放时统一写入一次——自然满足min_uses条件，避免 SSD 白写 -
搭配
inactive=10m和max_size=2g：加速淘汰未达阈值又无人再访的临时条目，防止缓存无序膨胀
上线后验证是否真在防占用
不能只看配置是否写了，要观察实际行为指标：
- 开启响应头：
add_header X-Cache-Status $upstream_cache_status;，采样分析长期MISS的路径是否与预期冷数据一致 - 统计缓存目录新建文件数：
find /var/cache/nginx/my_cache -type f -mmin -5 | wc -l，对比调参前后 5 分钟增量变化 - 检查日志中
$upstream_cache_status字段：若某类路径MISS占比下降、HIT上升，同时缓存总文件数增速放缓，说明生效
