redis pub/sub不支持服务端消息过滤，因广播逻辑硬编码于内核，lua仅能在publish前校验或结构化写入，无法干预已发出消息的投递。
Redis Pub/Sub 本身不支持服务端消息过滤，EVAL 脚本无法干预 PUBLISH 后的广播行为——你不能在 Lua 中“拦下”一条已发出的消息，再决定发给谁。
想在服务端“分类”，本质是放弃原生 Pub/Sub 的广播模型，改用「事件写入 + 脚本路由」混合模式。
为什么不能在 Lua 中过滤 Pub/Sub 消息
Pub/Sub 的投递逻辑硬编码在 Redis 内核中（pubsubPublishMessage 函数），Lua 运行在命令执行层，早于广播动作发生；它最多能做两件事：
– 在 PUBLISH 前检查条件（比如 EXISTS user:1001）
– 把消息结构化写入带业务语义的键（如 HSET event:123 type "order" user_id "1001"），再由消费者主动拉取判断
这两者都不属于 Pub/Sub 流程，也不具备实时广播特性。
用 EVAL 实现“伪精准分类”的典型误用
常见错误写法：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
redis-cli EVAL "if redis.call('GET', 'route:'..ARGV[1]) == 'shanghai' then redis.call('PUBLISH', 'region:shanghai', ARGV[2]) end" 0 1001 '{"order_id":"O123"}'
问题在于：
– ARGV[1] 是硬编码的用户 ID，无法从原始消息体中动态提取（Lua 不解析 JSON）
– 每次都要手动构造下游频道名，维护成本高
– 若 route:1001 不存在，脚本静默失败，无日志、无重试、无监控
– 多个 EVAL 并发执行时，无法保证顺序或幂等性
真正可行的 Lua + Pub/Sub 协作路径
把 Lua 当作“发布前守门员”和“结构化写入器”，而非“消息路由器”：
- 统一用
PUBLISH event:raw上游发原始消息 - 用
EVAL脚本完成：校验消息格式、提取关键字段（如user_id）、写入临时结构化键（SET event:123:user_id "1001"）、设置 TTL 防堆积 - 另起一个常驻服务（Go/Python）订阅
event:raw，收到后立即调用GET event:123:user_id获取路由信息，再PUBLISH到细分频道 - 所有消费者只订阅自己关心的频道（如
user:1001），不依赖 Lua 做运行时匹配
这样既利用了 Lua 的原子写入能力，又规避了它不能介入广播流程的根本限制。
频道命名与模式订阅的隐性成本
很多人试图用 PSUBSCRIBE user:* + Lua 解析消息体来模拟过滤，但要注意：
– PSUBSCRIBE 匹配是 O(n) 时间复杂度，活跃模式超 50 个就会明显拖慢整个 Pub/Sub 系统
– Redis 不支持 ** 或正则，user:*:order 可行，user:** 直接报错
– 每个订阅连接必须独占，不能复用，否则阻塞其他命令
所以“分类”应靠命名规约（如 service:order:user:1001）提前收敛，而不是靠运行时脚本或模式匹配去兜底。
