Redis Pub/Sub 无法直接清 Nginx 缓存，因为 Nginx 缓存是本地文件系统级、各 worker 进程隔离的磁盘缓存，且原生不支持订阅 Redis 消息；必须通过中间服务监听 Redis 消息后调用文件删除、USR1 信号或 /_purge 接口间接清理。
不能直接用 Redis 发布订阅触发 Nginx 本地缓存失效。
为什么 Redis Pub/Sub 无法直接清 Nginx 缓存
Nginx 的 proxy_cache、fastcgi_cache 等缓存是文件系统级的本地磁盘缓存，每个 worker 进程只读自己的缓存路径，不共享内存，也不监听外部事件。Redis 的 publish/subscribe 是纯消息通道，Nginx 原生不支持接收或响应这类消息——它没有内置的订阅客户端，也无法在收到 “invalidate /api/user” 消息后自动删除对应 key 的缓存文件。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
可行的间接联动方案
想让 Redis Pub/Sub 参与 Nginx 缓存失效流程，必须引入一个“中间协调者”，负责监听 Redis 消息并执行实际清理动作。常见做法如下：
-
部署独立的缓存清理服务：用 Python/Go/Node.js 写一个轻量服务，启动时订阅 Redis 频道（如
nginx:cache:invalidate），收到消息后解析路径或 key，调用rm -f删除对应缓存文件，或发送USR1信号触发 Nginx 缓存目录重建（需配合proxy_cache_path ... use_temp_path=off和合理哈希层级） -
通过 HTTP 接口触发清理：Nginx 配置一个内部
location /_purge，启用ngx_http_proxy_cache_purge模块（需编译时加入）。清理服务收到 Redis 消息后，向http://127.0.0.1/_purge/uri发起 DELETE 请求，由 Nginx 自身完成精准清除 -
统一使用带版本号的 cache_key：不主动删缓存，而是让业务发布更新时，同时推送新版本标识（如
v2）到 Redis；Nginx 配置中用set $cache_key "$host$request_uri?v=$version"; proxy_cache_key $cache_key;，这样旧缓存自然淘汰，无需手动清理
注意事项
直接暴力删缓存文件有风险：若正在被 worker 读取，可能造成 500 或返回截断内容；建议配合 proxy_cache_lock on 和 proxy_cache_lock_timeout 避免并发回源冲突。另外，务必限制 purge 接口仅允许内网访问，防止被恶意调用。
