nginx 原生无缓存失效钩子，proxy_cache_purge 是被动式 purge 请求触发的按需清除机制，不介入缓存流程；需通过 proxy_cache_bypass、proxy_no_cache 或 lua 动态控制缓存行为。
nginx 原生不提供“缓存失效钩子”这种可编程接口，proxy_cache_purge 并不是钩子，而是一个 HTTP 方法触发的清除机制。它不介入缓存命中流程，也不在请求到达时自动执行逻辑，而是依赖显式发起的 PURGE 请求来删除对应缓存项。
proxy_cache_purge 的本质是“按需清除”
它通过在 location 中配置 proxy_cache_purge 指令，将特定 URI（或带变量的 URI）映射为清除操作，而不是监听或拦截缓存行为：
- 必须手动发送
PURGE /xxx请求（如curl -X PURGE http://example.com/static/logo.png）才能触发清除 - 清除动作基于
proxy_cache_key计算出的 hash 值，精准匹配并删除磁盘上的缓存文件及内存索引 - 不支持自动感知后端变更、不监听数据库更新、也不提供回调或事件通知
真正影响缓存是否生效的控制点
若想实现类似“失效钩子”的效果，需组合使用原生指令在请求阶段动态干预，而非依赖 purge：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_cache_bypass：设为$arg_nocache或$http_x_no_cache，带参请求直接跳过缓存 -
proxy_no_cache：配合变量（如$cookie_admin），满足条件时禁止写入缓存 -
set_by_lua_block（OpenResty）：在 rewrite 阶段读取上游状态、查询 Redis 标记、或解析请求头，动态设置$skip_cache变量，再交由proxy_cache_bypass决策
为什么不能把 purge 当作钩子用
关键限制在于它的被动性和作用域：
- 仅响应 PURGE 方法，无法响应 POST/PUT/DELETE 等业务操作
- 无法获取后端响应体或状态码，不能根据
200 OK后的 payload 内容决定是否清除 - 不支持通配符批量清除（如
PURGE /api/v1/users/*），需配合 Lua 或外部脚本构造 URI 列表 - 清除动作无返回确认（默认返回 204），也不记录日志，调试困难
替代方案：模拟“失效钩子”的实用路径
若业务需要发布即清缓存，推荐以下轻量组合：
- 后端在更新数据后，调用一个内部 API（如
POST /_cache/invalidate） - Nginx 用
location = /_cache/invalidate接收，用content_by_lua_block解析 body 中的路径前缀，生成 PURGE 请求发给自身（loopback）或调用ngx.location.capture转发 - 或更简单：用
map指令定义清除规则，配合if ($invalidated) { return 204; }+ 外部定时清理脚本
