缓存键设计不负责清理过时规则，只决定命中与精准purge；需先替换所有proxy_cache_key配置并重载，再按旧key规则主动清除残留缓存，最后通过版本标识和业务前缀提升可维护性。
缓存键设计本身不负责“清理”过时规则，它决定的是缓存能否被正确命中和精准 purge。所谓“清理过时的缓存键映射规则”，本质是两件事：一是停用旧 key 规则并确保新规则生效；二是清除仍由旧 key 生成、但已不再使用的缓存条目。
停止旧缓存键的继续使用
旧 key 规则只要还在配置中被引用（比如 proxy_cache_key 指向它），Nginx 就会持续按该规则生成新缓存，无法真正“过时”。所以第一步是彻底替换：
- 在所有
location或server块中，把旧的proxy_cache_key表达式（如$host$request_uri）全部替换成新设计（推荐$scheme$request_method$host$uri$is_args$args） - 如果用了不同缓存区（
keys_zone），确保每个 zone 对应的 key 规则统一且明确，避免混用 - 重载 Nginx 配置（
nginx -s reload），让 worker 进程加载新规则
清除残留的旧缓存条目
已用旧 key 写入的缓存不会自动消失，必须主动清理。不能靠等 inactive，因为旧 key 生成的路径与新 key 不同，它们共存于同一缓存目录，但互不可见、无法批量 purge：
- 若启用
ngx_cache_purge，需用旧 key 规则重新构造一批 PURGE 请求——例如旧 key 是$host$request_uri，就对每个待清 URL 发送PURGE http://example.com/path（不含 query 参数或含法需严格匹配） - 若未启用 purge 模块，可脚本化删除：根据旧 key 规则计算 MD5，还原哈希路径（如
md5("example.com/path") → ab/cdef1234...），再用find /var/cache/nginx -path "*/ab/cdef1234*" -delete定向清除 - 慎用
rm -rf整目录清理：会清掉所有缓存（含新 key 的），引发回源风暴；仅适用于灰度切换、可接受全量失效的场景
避免未来出现“键规则过时”问题
关键在于让缓存键具备可追踪性与业务语义，而不是频繁变更：
- 把业务维度固化进 key：如文章类接口统一加前缀
/api/v1/posts/，清理时可用正则匹配生成 key 列表，而非依赖 URL 字面量 - 在 key 中加入版本标识（如
$cache_version$scheme$host$uri），升级时只需改 version 变量，旧缓存自然隔离，无需手动扫 - 记录每次 key 规则变更的时间、范围和影响 URL，配合监控（如
X-Cache-Status统计 HIT 率下降趋势），验证旧 key 是否真正退出服务
缓存键不是一次写完就不管的配置项，它是缓存生命周期管理的起点。设计时多一分确定性，后续清理就少十分混乱。
