pub/sub 频道命名必须带租户前缀，采用三段式结构{租户标识}:{业务域}:{实体id}，禁用裸频道和通配符泛订阅；acl需按前缀精确控制，显式授权+subscribe/+publish；tls与消息体加密必须同时启用；pub/sub不可替代可靠队列，应改用stream或list。
Pub/Sub 频道命名必须带租户前缀
不加前缀的 SUBSCRIBE internal:orders 是生产环境高危操作——频道名一旦暴露，任何能连上 Redis 的客户端都能监听或伪造消息。银行不敢碰 OpenClaw，部分原因就是这类“裸奔频道”在内部系统里太常见。
正确做法是强制绑定业务主体，用三段式结构：{租户标识}:{业务域}:{实体ID}。比如订单变更只允许订阅 tnt_01:order:12345，而不是泛泛的 order:* 。
- 通配符订阅（
PSUBSCRIBE）要严格限制前缀范围，例如PSUBSCRIBE tnt_01:inventory:*，禁止PSUBSCRIBE * - 避免使用纯数字或 UUID 作第一段，如
123:order:xxx—— 容易被枚举，应改用哈希后固定长度标识，如tnt_a7f2:order:xxx - 测试环境可放宽，但上线前必须扫描所有
SUBSCRIBE/PSUBSCRIBE调用点，确认无硬编码敏感频道名
ACL 权限必须按频道前缀精确控制
Redis 6.0+ 的 ACL 不是“开了就行”，ACL SETUSER pubuser on >pass ~* +subscribe 这种写法等于没设防——~* 允许访问全部频道。
真正起作用的是带波浪线的模式匹配 + 明确指令白名单。权限粒度必须卡死到租户级别。
- 创建用户时用
~tnt_01:* &*：前者限定可操作的键/频道前缀，后者限定仅允许 Pub/Sub 类命令（Redis 6.2+ 才支持&*） - 必须显式授予
+subscribe和+publish，不能靠+@all或+@pubsub模糊放行 - 检查权限是否生效：用该用户连接后执行
ACL LIST，确认输出中含~tnt_01:* &*和对应指令
TLS 加密和消息体加密不能二选一
只开 TLS 而不加密消息体，等于快递盒贴了封条但里面装的是明信片；只加密消息体而不用 TLS，则密文在传输层就被嗅探截获。两者必须同时启用。
尤其注意：TLS 是通道安全，解决中间人问题；应用层加密（如 AES-256-GCM）是内容安全，防内部人员或越权用户直接读取频道消息。
- Redis 配置中必须启用
tls-port并设置tls-auth-clients yes，禁用非 TLS 的port - 敏感字段（如用户身份证、银行卡号）不能依赖频道名隔离，必须在序列化前用
Fernet或cryptography.hazmat.primitives.ciphers加密 - 密钥管理别硬编码——用环境变量传入密钥密文，启动时解密加载，避免密钥出现在进程内存 dump 中
别把 Pub/Sub 当可靠队列用
很多人用 PUBLISH/SUBSCRIBE 替代消息中间件，结果发现消息丢了、顺序乱了、消费者宕机后收不到历史消息——这不是配置问题，是设计误用。
Pub/Sub 本质是广播管道，没有持久化、无 ACK、无重试、不保证顺序。它适合事件通知（如“库存更新了”），不适合任务分发（如“请处理这笔退款”）。
- 需要可靠性？换
Stream：用XADD/XREADGROUP，支持消费者组、ACK、pending list、消息重播 - 需要削峰？别压 Pub/Sub，改用
List+BRPOP或Stream，二者都支持阻塞读与失败重入 - 如果已有大量 Pub/Sub 代码，至少加一层兜底：发布前先
LPUSH backup_queue存一份快照，订阅端异常时从备份拉取
实际部署中最容易被跳过的，是 ACL 权限与频道命名的联动验证——写了 ~tnt_01:* 却忘了删掉旧账号的 default 用户权限，或者频道名拼错一个字符导致 ACL 失效。这种问题不会报错，只会悄悄漏数据。
