proxy_cache_min_uses 是缓存落盘阈值而非禁用缓存，需配合精简 proxy_cache_key 和启用 proxy_cache_lock 才生效；按资源类型分层配置：静态资源设为2，首页/api设为1，用户路径设为2–3并剔除干扰参数，上报接口应绕过缓存。
proxy_cache_min_uses 不是让请求“不缓存”，而是把缓存写入磁盘的门槛提上去——只有同一缓存 key 被访问达到指定次数，响应体才真正落盘。这样能精准过滤掉调试、爬虫、带随机参数的埋点等低频长尾请求，避免它们生成大量“写一次就丢”的小文件，挤占磁盘空间和 keys_zone 内存。
按路径语义分层配置，别全局一刀切
不同资源复用规律差异很大，统一设值容易误伤或失效： - 静态资源（`.js/.css/.png/.woff2`）：设为 `2`。过滤单次 CI 预览、爬虫扫描、本地调试，保留真实用户二次加载价值 - 首页 `/` 或公共 API 入口（如 `/api/config`）：保持 `1`。天然高复用，首次缓存即合理，利于快照一致性 - 带用户标识路径（如 `/user/123`、`/order?id=456`）：设为 `2` 或 `3`，但必须先精简 `proxy_cache_key`，剔除会话 ID、时间戳等干扰参数 - 上报接口（如 `/log?t=xxx&r=yyy`、`/beacon`）：不用 `min_uses`，直接用 `proxy_no_cache 1` 或 `proxy_cache_bypass $arg_r $arg_t` 绕过整个缓存模块精简 cache_key 是生效前提
如果 `proxy_cache_key` 包含 `$args` 或 `$request_uri`，那每个带不同随机参数的请求都会被当成新 key，计数永远归零，`min_uses` 形同虚设： - 静态资源建议：`proxy_cache_key "$scheme$host$uri";`（彻底排除查询参数） - 动态接口建议：`proxy_cache_key "$scheme$host$uri$is_args$arg_uid$arg_tid";`（只保留业务必需参数） - 可配合 `map` 指令预处理非法参数，再通过 `proxy_cache_bypass` 控制跳过必须启用 proxy_cache_lock，否则前几次请求仍会并发回源
只设 `min_uses 2` 而不加锁，前两次请求可能同时穿透后端，各自尝试写缓存，反而增加 SSD 写压力和后端负载： - `proxy_cache_lock on;` - `proxy_cache_lock_timeout 5s;`（略大于后端 P95 响应时间） - 第 1 次请求回源 + 加锁；第 2 次请求等待锁释放，不重复发起；锁释放时统一写入一次，自然满足 `min_uses=2` 条件验证是否真在节省磁盘和内存
不能只看配置写了没，要观察实际效果： - 响应头加 `add_header X-Cache-Status $upstream_cache_status;`，重点监控哪些路径长期 `MISS` 却无后续 `HIT` - 统计缓存目录新建文件数：`find /var/cache/nginx/my_cache -type f -mmin -5 | wc -l`，对比调参前后 5 分钟增量变化 - 查 keys_zone 内存占用率变化，以及 access log 中 `X-Cache-Status` 字段分布比例不复杂但容易忽略
