Nginx 中 proxy_cache_purge 设计缓存更新通知

Nginx proxy_cache_purge 需由发布系统主动触发，关键在于确保 purge 请求的 key 与 cache_key 完全一致、路径可控、执行可验，并作为发布流水线一环集成于部署脚本末尾，配合白名单、Token 校验与日志审计实现安全闭环。

要让 Nginx 的 proxy_cache_purge 在缓存更新时自动响应，关键不是“监听”后端变化，而是把缓存清理动作变成发布流程中可触发、可验证、可收敛的环节。它本身不支持事件订阅或回调，必须靠外部系统主动调用 purge 接口，因此设计重点是：让通知路径清晰、键值精准、执行安全。

缓存更新通知 = 可控的 purge 请求触发

后端内容更新（如 CMS 发布、API 数据变更、CI/CD 部署完成）后，需由发布系统同步发出一个 HTTP PURGE 或 GET 请求到 Nginx 的 purge 接口。这不是被动通知，而是主动指令。

1. 推荐在部署脚本末尾加入 curl 命令，例如：curl -X PURGE "https://cache.example.com/purge/api/v1/posts/456"
2. 若更新涉及多个路径（如某分类下全部文章），用脚本生成批量 URL 列表，逐个或并发调用（注意速率限制）
3. 避免在应用代码里硬编码 purge 地址；应通过配置中心或环境变量注入，便于多环境切换

确保 purge key 与 cache_key 完全一致

通知能否生效，取决于请求构造的 key 是否和缓存时生成的 key 完全相同。任何差异（比如大小写、参数顺序、是否含 Host 头）都会导致“删了但没删掉”。

1. 检查 proxy_cache_key 配置，例如："$scheme$request_method$host$uri$is_args$args"
2. purge location 中的 key 表达式必须镜像该逻辑，例如：proxy_cache_purge my_cache "$scheme$request_method$host$1$is_args$args";（其中 $1 是正则捕获的路径）
3. 负载均衡场景下，$upstream_addr 必须同时出现在 cache_key 和 purge key 中，否则跨节点清理会失效

把 purge 接口做成“带上下文的发布钩子”

不要把它当成通用管理接口，而应视作发布流水线的一环——只接收来自可信发布源的、带业务语义的清理请求。

1. 用 map 指令将请求参数（如 ?service=blog&id=789）映射为实际缓存路径，实现语义化 purge
2. 配合 X-Purge-Source: ci-cd-v2 请求头 + IP 白名单 + Token 校验，明确知道谁在什么时候清了什么
3. 记录 access log，保留 $request、$status、$remote_addr，用于审计与故障回溯

验证通知是否真正落地

收到 200 响应只是说明 Nginx 接收并尝试执行，并不代表缓存已清除。必须做二次确认：

1. 立刻用原始请求复现（如 curl -I https://example.com/api/v1/posts/456），检查响应头 X-Cache-Status 是否从 HIT 变为 MIS 或 MISS
2. 若需强验证，可临时开启 proxy_cache_lock on 并观察首次回源日志，确认后端确实被拉取
3. 对高频核心接口，建议加轻量健康检查：定期请求 + 断言缓存状态，形成闭环反馈