不能在subscribe后用eval发消息，因为pub/sub连接与lua执行环境完全隔离，仅允许subscribe/unsubscribe/ping/quit命令；eval只能在普通连接中调用publish，且仅限原子化发布决策。
为什么不能直接在SUBSCRIBE后用EVAL发消息？
因为Redis的发布订阅（Pub/Sub）和Lua脚本运行在完全隔离的执行路径上：SUBSCRIBE会让客户端进入阻塞等待模式，而EVAL必须在非阻塞的命令上下文中执行——两者根本无法共存于同一个连接。试图在已订阅的连接里执行Lua脚本，会直接报错ERR only (P)SUBSCRIBE / (P)UNSUBSCRIBE / PING / QUIT allowed in this context。
- Pub/Sub连接是“单向监听通道”，不参与命令队列调度，也不支持事务或脚本执行
- Lua脚本只能由普通命令连接触发，且脚本内**无法调用
PUBLISH以外的Pub/Sub相关命令**（如SUBSCRIBE、PSUBSCRIBE在脚本中非法） - 真正能结合Lua增强的，是“发布前”的决策逻辑，不是“订阅端”的响应逻辑
EVAL里调用PUBLISH的边界在哪？
可以，但仅限原子化封装“是否发、发给谁、发什么”的判断链路。源码层面，PUBLISH在src/pubsub.c#L391被pubsubPublishMessage处理，它不依赖客户端状态，纯服务端广播，因此Lua中调用安全。
-
PUBLISH在脚本中是普通命令，支持redis.call('PUBLISH', KEYS[1], ARGV[1]) - 但KEYS只能传频道名（字符串），不能传通配符或模式——
PSUBSCRIBE逻辑不在脚本作用域内 - 脚本里无法得知当前有哪些客户端在线订阅了该频道（
server.pubsub_channels字典对Lua不可见） - 若需“按条件批量发布”，建议把频道列表作为
KEYS参数传入，循环调用PUBLISH
redis-cli EVAL "for i=1,#KEYS do redis.call('PUBLISH', KEYS[i], ARGV[1]) end" 2 news sports "alert: server restart"
如何避免Lua+Pub/Sub引发超时或雪崩？
默认5秒脚本超时（src/scripting.c#L576）在高频发布场景下极易触发SCRIPT KILL，尤其当频道订阅者过多导致O(n)模式匹配耗时上升时。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 脚本内避免遍历大集合或嵌套循环；频道名尽量用精确匹配，少用
PSUBSCRIBE通配符 - 不要在脚本中尝试读取订阅者数量（无对应API），也别用
CLIENT LIST这类管理命令（禁止在脚本中调用） - 若需限流，用
INCR+EXPIRE在脚本内实现计数器，而非依赖外部协调 - 生产环境建议通过
lua-time-limit配置项适当放宽超时（如设为10000），但需同步监控script_time_limit_exceeded指标
替代方案：什么时候该放弃Lua，改用其他机制？
当你需要“订阅端动态响应”“消息持久化”“失败重试”或“跨服务路由”时，Lua+Pub/Sub就到头了——它本质仍是无状态、无确认、无回溯的fire-and-forget模型。
- 实时聊天需消息回执？用Stream + consumer group，配合
XREADGROUP和ACK - 事件要落库+通知？走业务层双写，或用Redis Streams + 外部worker监听
- 需要广播+过滤+转换？考虑Kafka或NATS，Redis Pub/Sub不适合复杂消息管道
- 哪怕只是加个“发布成功后删临时键”，也比硬塞进Lua脚本更清晰可靠
Pub/Sub和Lua的交集很窄：只适合“发布动作本身需要原子条件判断”的瞬间决策。多一步逻辑，就该让出控制权。
