Redis Pub/Sub 框架原生不支持在服务端进行消息过滤，广播逻辑被硬编码在核心代码中，Lua 脚本无法介入。开发者只能在 PUBLISH 执行前加入校验逻辑，或通过结构化键值对写入消息，但无法拦截已发出的消息。简言之，EVAL 脚本无法干预 PUBLISH 之后的广播流程：你无法在 Lua 中拦截已发布的消息并决定其分发对象。
如果必须实现服务端消息分类，就需要放弃原生广播模型，转而采用“事件写入 + 脚本路由”的混合架构。
为何无法在 Lua 脚本中过滤 Pub/Sub 消息
Pub/Sub 的消息投递逻辑被硬编码在 Redis 内核中（即 pubsubPublishMessage 函数），而 Lua 脚本运行在命令执行层，其执行时机早于广播动作。因此，Lua 脚本最多只能实现以下两个功能：
- 在
PUBLISH前执行条件检查，例如验证EXISTS user:1001键是否存在； - 将消息结构化为带有业务语义的键值存储，例如
HSET event:123 type "order" user_id "1001"，然后由消费者主动拉取并判断。
这两种操作都不属于 Pub/Sub 流程，也不具备实时广播特性——因此，不要指望在 Lua 中直接拦截广播消息。
使用 EVAL 实现“伪精准分类”的常见误区
许多开发者可能会写出类似如下的代码：
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，接收到消息后立即从临时键中获取路由信息，然后PUBLISH到细分频道。 - 所有消费者仅订阅自身关注的频道（例如
user:1001），不依赖 Lua 进行运行时匹配。
这种方案既利用了 Lua 的原子写入能力，又规避了其无法介入广播流程的根本限制。
频道命名与模式订阅的隐藏成本
许多人尝试使用 PSUBSCRIBE user:* 结合 Lua 解析消息体来模拟过滤，但有几点需要注意：
PSUBSCRIBE的模式匹配具有 O(n) 时间复杂度，当活跃模式数量超过 50 个时，会显著拖慢整个 Pub/Sub 系统。- Redis 不支持
**或正则表达式，user:*:order是可行的，但user:**会直接报错。 - 每个订阅连接必须独占使用，不能复用，否则会阻塞其他命令的执行。
因此，消息“分类”应通过命名规约提前收敛——例如 service:order:user:1001 这种结构——而不是依赖运行时的脚本或模式匹配来兜底。
