调高 fastcgi_cache_min_uses 不能提升缓存留存率，它仅控制写入时机而非生命周期；真正决定留存的是 inactive 和 use_stale 配置，且 cache_key 必须包含足够区分维度以避免内容错乱。
直接调高 fastcgi_cache_min_uses 并不能提升热点资源的缓存留存率——它只控制“第几次才写入”，不负责“写入后留多久”。真正影响留存率的是缓存写入后的生命周期管理，而 min_uses 的核心价值在于：**让缓存只由真实、稳定的高频请求触发，避免偶发访问污染缓存空间，从而为真正需要长期留存的热点内容腾出位置和优先级。**
精准识别并锁定高频热点接口
缓存留存的前提是“该缓存确实被反复需要”。如果接口本身流量稀疏或波动大，再怎么调 min_uses 也留不住有效内容。
- 用 Nginx 日志 + 简单脚本统计 URI+args 组合的 5 分钟/10 分钟访问频次，筛选出稳定 >50 次/分钟的路径
- 对这类路径单独配置 location 块，关闭通用兜底规则干扰
- 确认后端响应头中不含
Cache-Control: no-cache或Set-Cookie（会默认禁用 FastCGI 缓存）
合理设置 min_uses 阈值，过滤“伪热点”
设得过低（如默认 1），调试请求、健康检查、爬虫试探都可能误写缓存；设得过高（如 10），真实但初期流量尚未爬升的热点又进不来。
- 对已确认的稳定热点接口，设为 2 或 3：前 1–2 次走后端验证响应一致性，第 3 次起开始缓存，兼顾冷启动与防污染
- 对调用节奏极快的 API（如秒级轮询），可设为 1，但必须配合更严格的
inactive（如inactive=30s）快速淘汰 - 对管理类、用户私有接口，直接在 location 中加
fastcgi_cache off，不参与缓存逻辑
用 inactive 和 use_stale 构建留存保障闭环
min_uses 决定“谁有资格进”，inactive 和 use_stale 才决定“能留多久、出问题了还靠不靠谱”。
-
inactive=5m：5 分钟内无再次命中即标记为可回收，适合高更新频率的热点数据（如实时行情页） -
inactive=1h：适用于内容稳定、访问持续的热点（如产品详情页、API 文档首页） -
fastcgi_cache_use_stale error timeout http_500 http_503：后端短暂故障时仍返回旧缓存，避免雪崩式回源冲垮留存窗口
cache_key 必须带区分维度，否则 min_uses 形同虚设
如果所有请求共用一个粗粒度 key（比如只含 $request_uri），那即使设 min_uses 10，不同用户的请求也会因 URI 相同而“搭便车”写入同一缓存项，导致内容错乱或无效覆盖。
- 公开页面缓存建议 key：
"$scheme$request_method$host$request_uri$args"（含参数） - 需区分用户角色的接口，加入 header 标识：
"$http_x_user_type$request_uri" - 绝对避免把登录态接口（含 Cookie）和静态资源混在同一 cache zone
