频道名禁用空格和，因空格致客户端分词错误、频道不一致，在subscribe中误触发模式订阅；多租户必须用tenant:{id}:前缀并服务端校验，推荐小写、点号/下划线分层、≤64字符。
频道命名不是“能不能用”的问题，而是“会不会出事”的问题——名字写错一个字符，就可能漏收消息、跨租户泄露、日志解析失败，甚至被当成通配符误触发模式订阅。
频道名里为什么不能出现空格和 * ?
空格会让部分客户端（比如老版本 Jedis）在解析 SUBSCRIBE 命令时直接分词错误，"user:123" 和 "user:123 " 是两个完全不同的频道，但你根本看不出差别；* 和 ? 在 PSUBSCRIBE 中有特殊含义，如果误用在普通 SUBSCRIBE 里（比如 SUBSCRIBE logs.*），Redis 不会报错，但实际启动的是模式订阅，行为彻底偏离预期。
- 空格、制表符、换行符：导致命令解析歧义或频道名不一致
-
*、?：仅应在PSUBSCRIBE场景下显式使用，普通订阅必须避开 - 前导/尾随空格：必须用
trim()清洗，否则"user:123"和" user:123 "无法互通
多租户场景下必须带 tenant:{id}: 前缀
Redis 本身没有租户概念，tenant:abc123:order_updated 和 tenant:def456:order_updated 对它来说只是两个字符串。隔离全靠应用层硬约束：所有频道名必须以可信租户 ID 为前缀，且该 ID 必须来自 JWT 或服务端上下文，绝不能直接拼接前端传入的参数。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- ✅ 正确格式：
tenant:abc123:notifications（语义清晰、可 ACL 控制） - ❌ 危险格式：
abc123:notifications（缺少tenant:前缀，易与其他业务冲突） - ❌ 严禁格式：
user:789:notifications（用户 ID 跨租户重复，无隔离意义） - ⚠️ 特殊字符处理：租户 ID 含
/或:时，必须做 URL-safe 编码，例如用encodeURIComponent()
为什么推荐用点号 . 或下划线 _ 分层，且长度 ≤64 字符
分层结构（如 metrics.db.redis.latency）不是为了取悦人眼，而是为了让运维、监控、ACL 策略能按层级匹配；全部小写避免不同客户端对大小写的处理差异；长度限制则关乎性能——超 256 字符后，PUBSUB CHANNELS 返回结果在终端里容易折行错乱，哈希计算开销也会上升。
- 层级分隔符只用
.或_，不用-或/（后者在某些 ACL 工具中需转义） - 禁用中文、emoji、控制字符：日志系统、审计平台、Redis CLI 输出都可能截断或乱码
- 动态拼接时必须清洗：用户输入的 ID、订单号等，要先过滤非英文数字下划线点号，再拼接
最常被忽略的一点：频道名一旦上线，就很难改——所有客户端、监控规则、ACL 策略、历史日志都绑定了它。定名不是写代码，是立契约。
