Redis Pub/Sub 是即发即弃的广播机制，不持久化、不重放、不保证送达，适用于实时通知等场景，不适用于需可靠投递的订单履约等业务。
Redis Pub/Sub 是广播，不是队列
这里有个关键认知需要厘清：Redis 的 PUBLISH/SUBSCRIBE 机制，本质上是一种“即发即弃”的广播。消息发出后，所有在线的订阅者能收到，但也就到此为止了——它不存盘、不重放、更不保证送达。这跟 Kafka 或 RabbitMQ 那种带持久化和确认机制的消息队列，完全是两码事。
- 适合什么场景？ 实时性要求高、允许少量丢失的场景，比如系统告警弹窗、聊天室消息推送、状态变更广播（例如“订单已支付”这种通知）。
- 不适合什么场景？ 订单履约、支付回调、审计日志——这些业务需要至少一次投递和失败重试机制，Pub/Sub 无法胜任。
- 一个典型的错误用法是，用
SUBSCRIBE来监听后台任务。结果进程一重启，离线期间的所有消息就全丢了。 - 记住，Redis 不会为订阅者缓冲任何消息。客户端一旦断开重连，必须重新执行
SUBSCRIBE，而中间错过的消息，就永远找不回来了。
用 redis-cli 快速验证 Pub/Sub 流程
动手写代码之前，不妨先用命令行验证一下链路是否通畅。这往往是排查“为什么前端收不到消息”最直接有效的一步。
- 新开两个终端，分别执行
redis-cli连接到你的 Redis 服务。 - 在第一个终端输入：
SUBSCRIBE news—— 此时它会进入阻塞监听状态。 - 在第二个终端输入：
PUBLISH news "hello from redis"—— 立刻就能在第一个终端看到消息回显。 - 注意，
news是频道名，大小写敏感；多个订阅者可以同时监听同一个频道，彼此互不影响。 - 如果看不到回显，优先检查 Redis 配置：是否启用了
protected-mode no（本地测试常用），或者是否只绑定了127.0.0.1而非0.0.0.0。
Lara vel / Spring / Go 中的“广播”其实都绕不开 RedisTemplate 或 publish 命令
各种框架的广播封装，本质上只是帮你自动处理了连接、序列化和频道路由，底层调用的依然是 Redis 原生的 PUBLISH 命令。理解这一点，才能准确判断问题出在业务逻辑，还是配置层面。
- Lara vel：实现了
ShouldBroadcast接口的事件，最终会触发RedisBroadcaster::broadcast()，其核心代码就是一句$this->connection->publish($channel, $payload)。 - Spring Data Redis：
RedisTemplate.convertAndSend("topic", obj)方法底层调用的也是PUBLISH，而非用于队列的LPUSH。 - Go：像
go-socket.io这类库配合 Redis 适配器，本质是将每个 socket 连接映射为一个订阅者，依靠 Redis 来同步房间成员状态和广播消息。 - 一个隐蔽的陷阱：Lara vel 默认使用
redis驱动广播，但如果你在.env里误写了BROADCAST_DRIVER=pusher却没配置 Pusher 密钥，事件照常会被分发，但根本不会发往 Redis —— 而且日志里很可能没有任何报错。
生产环境必须面对的三个现实问题
Pub/Sub 在单机开发时顺风顺水，一上生产环境就容易“翻车”。问题的核心往往不在于 Redis 本身，而在于架构设计的预期和客户端行为。
- 连接数爆炸：每个活跃的 Websocket 连接通常对应一个 Redis 订阅连接。1万用户在线，理论上就需要近1万个 Redis 客户端连接。而 Redis 默认的
maxclients设置通常是 10000，这就可能刚好卡住上限，导致新用户无法连接。 - 频道泛滥：如果按用户 ID 动态创建频道（例如
user:123），10万用户就意味着10万个频道。Redis 不会自动清理空闲频道，这会导致内存缓慢增长，同时使用PUBSUB NUMSUB命令查询时性能也会下降。 - 权限失控：原生的 Redis Pub/Sub 没有任何内置的鉴权机制。如果将 Redis 实例暴露到公网（哪怕只开了一个端口），任何人都可以执行
SUBSCRIBE *来监听所有频道——工信部安全通告中提及的 OpenClaw 等风险，就包含这一条。
所以说，真正的难点不在于如何发送一条消息，而在于想清楚：谁该接收、接收多久、以及收不到该怎么办。频道命名设计、连接池复用、消息投递降级方案（例如失败时回退到 Server-Sent Events 轮询），这些思考远比敲下一行 PUBLISH 命令要重要得多。
