pub/sub与list根本不是同类机制：pub/sub是纯内存瞬时广播，消息发即丢，无确认无重试；list是持久化队列，消息存留至被消费，支持阻塞读取与单消费者争抢。
Redis发布订阅（Pub/Sub）和List做队列，根本不是同一类东西——别拿它们当替代方案直接换，否则线上丢消息、重复消费、扩缩容踩坑都是分分钟的事。
Pub/Sub 消息一发就丢，List 能存着等你来取
Pub/Sub 的消息是纯内存瞬时广播：PUBLISH 一执行，消息立刻推给所有当前在线的 SUBSCRIBE 客户端；如果没人在线，或者订阅者网络断开，消息直接消失，连日志都不留。List 则不同：LPUSH 进去的消息会一直留在键里，直到被 RPOP 或 BRPOP 拿走——哪怕消费者宕机半小时，重启后照样能继续消费。
- 典型误用：用
SUBSCRIBE接收订单创建事件，结果运维重启了订阅服务，期间产生的 200 条订单全丢了 - List 的持久性依赖于 Redis 本身是否开启 RDB/AOF；而 Pub/Sub 连这个层面都不涉及
-
BRPOP的阻塞行为是可控的，SUBSCRIBE的阻塞是“永远监听”，一旦连接断开就得重连+重订阅，中间无状态补偿
多个消费者场景下，Pub/Sub 是广播，List 是争抢
一个频道 order:paid，三个微服务实例都 SUBSCRIBE 它，那每条支付成功消息都会被三台机器同时收到——这是广播，不是负载均衡。而同一个 List 键，比如 order:queue，三个实例都用 BRPOP，谁先抢到谁处理，天然实现任务分发。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 想让多实例协作消费？Pub/Sub 不行，得自己加去重逻辑或业务层路由
- List 的争抢靠 Redis 原子命令保证，无需额外锁；但要注意
BRPOP超时设置不合理会导致空轮询或延迟升高 - 如果真需要广播 + 可靠，别硬改 Pub/Sub，直接上
Stream，用XADD+XREADGROUP，它支持多消费者组+ACK+pending list
Pub/Sub 没有确认机制，List 可以手动 ACK
Pub/Sub 下，SUBSCRIBE 客户端收到消息后，Redis 根本不关心你处理没处理完、有没有失败、要不要重试——它发完就清内存。List 虽然也没内置 ACK，但你可以自己设计：RPOP 出来先存到临时 key，处理成功再 DEL，失败则回填或转死信队列。
- 常见翻车点：用
SUBSCRIBE做异步邮件发送，某次邮件服务超时，消息已发出但未送达，无法重试 - List 方案里，
BRPOP+ 处理 +DEL是最小可靠单元；若怕DEL失败导致漏删，可用LREM配合唯一 message ID - 注意：不要用
RPOP+ 业务处理 +DEL，万一处理中崩溃，消息就丢了；必须用阻塞式命令保底
集群环境下，Pub/Sub 的 channel 分布和 List 的 key 分布逻辑完全不同
在 Redis Cluster 中，List 的 key 由 CRC16 hash 决定落在哪个 slot，进而决定在哪台节点上；但 Pub/Sub 的 SUBSCRIBE 是客户端直连任意节点，该节点只负责转发本节点上的订阅关系——跨节点消息要靠内部 gossip 同步，延迟不可控，且 PUBLISH 返回值只反映本地订阅数，不是全局。
- 现象：集群里往
chat:room1发消息，只有连在同节点的订阅者能秒收，其他节点订阅者可能延迟几百毫秒甚至丢消息 - List 没这个问题：只要 key 落在某个节点，所有对该 key 的读写都路由到它，语义确定
- 如果你的应用已上集群，又强依赖 Pub/Sub，务必测试各节点间消息到达一致性；不如直接切
Stream，它对集群友好得多
真正关键的不是“哪个快”，而是“消息能不能丢”——Pub/Sub 快在无状态广播，List 慢在要落盘+争抢，但慢换来的是一致性和可追溯性。别被文档里“适合实时通知”带偏，先问自己：这条消息，业务上允许重发吗？允许丢失吗？需要多个系统各自独立响应，还是协同完成一件事？答案出来，选型自然清楚。
