不能复用同一redis客户端实例做pub/sub和get/set，因subscribe后连接进入订阅模式，仅允许有限命令，get/set等会报错；应创建两个独立客户端：一个专用于pub/sub，另一个用于数据操作。
为什么不能复用同一个 redis 客户端实例做 pub/sub 和 get/set？
因为 Redis 协议规定：一旦客户端执行 SUBSCRIBE，该连接就进入“订阅模式”，此后只允许接收消息或执行 PING/QUIT/(P)UNSUBSCRIBE 等有限命令；任何 GET、SET、DEL 都会立刻报错：ERR only (P)SUBSCRIBE / (P)UNSUBSCRIBE / PING / QUIT allowed in this context。
这个限制不是 Node.js SDK 的 bug，而是 Redis 服务端强制行为。哪怕你先 SUBSCRIBE 再 UNSUBSCRIBE，连接状态也不会自动恢复为普通命令模式（redis@4+ 尤其严格）。
- 错误写法示例：
client.subscribe('x'); await client.get('y')→ 必然失败 - 即使没调用
subscribe，只要客户端被用于 Pub/Sub 流程（比如调过duplicate()后又连上），内部 socket 状态也可能被标记为“不可发普通命令” - 别指望重连能绕过——连接重建后状态重置，但业务逻辑里混用仍极易触发异常
应该创建几个客户端实例？
两个就够了：一个专用于 Pub/Sub（支持 subscribe 和 publish），另一个专用于数据操作（get、set、hgetall 等）。
PUBLISH 是普通命令，不需要独立连接，它不改变订阅状态，所以可以安全地由 Pub/Sub 客户端发出；没必要再额外建第三个 publisher 实例——纯属冗余，还增加连接数和管理成本。
- ✅ 推荐结构：
const pubSubClient = createClient(...); const dataClient = createClient(...) - ❌ 不推荐三实例（subscriber/publisher/dataStore）：资源浪费，且 publisher 和 subscriber 共享同一连接池时反而容易因状态污染出问题
- 如果要用
pSubscribe（模式订阅），也只需在pubSubClient上调用，无需新客户端
如何避免连接未就绪就调用 subscribe 或 publish？
Node-Redis v4+ 的 connect() 是异步的，但 subscribe() 和 publish() 不会自动等待连接完成——直接调用会报 Client is not connected 错误。
必须显式 await 连接完成，且建议加上错误监听，否则连接失败时整个流程静默卡住。
- 正确写法：
await pubSubClient.connect();<br>pubSubClient.on('error', err => console.error('Pub/Sub client error:', err));<br>await pubSubClient.subscribe('events', handler); - 不要省略
await——pubSubClient.connect()返回 Promise，不 await 就调subscribe属于竞态 - 生产环境建议为两个客户端分别配置
socket.reconnectStrategy和socket.maxRetriesPerRequest，避免一个连接抖动拖垮另一个
duplicate() 方法是否安全？
可以，但仅限快速原型；不推荐在生产中依赖 client.duplicate() 创建订阅客户端。
因为 duplicate() 复制的是当前 client 实例的配置，但底层 socket 并非完全隔离——尤其在连接尚未建立或重连过程中，父子 client 可能共享未清理的状态，导致 subscribe 失败或命令被丢弃。
- 稳妥做法：始终用独立
createClient()调用初始化两个客户端 - 若坚持用
duplicate()，务必确保原 client 已connect()完成，且 duplicate 后立即调connect()并 await - 注意：
duplicate()创建的实例无法继承原 client 的事件监听器，需单独绑定error、ready等事件
