必须在应用层鉴权控制订阅权限，Redis本身不支持频道级订阅限制；服务端需校验token生成频道白名单供客户端订阅，命名应带业务前缀与权限粒度，避免PSUBSCRIBE和泛化频道名。
怎么让不同用户只能收自己权限内的频道消息
Redis 本身不校验“谁该订阅哪个频道”，SUBSCRIBE 是客户端直连后自由执行的命令。想实现权限隔离，必须在应用层拦截和控制——不是靠 Redis 配置，而是靠服务端在建立订阅前做鉴权。
典型做法是：用户连接 WebSocket 或长轮询时，先携带 token 请求「获取可订阅频道列表」；后端解析 token 得到角色/租户/用户 ID，查 DB 或缓存生成白名单（如 ["user:123:notify", "team:456:alert"]），再把该列表透传给客户端用于 SUBSCRIBE。Redis 服务器全程只管转发，不参与权限判断。
- 千万别把频道名硬编码成
all_users或admin这类泛化名称，否则一订阅就全量接收，权限形同虚设 - 频道命名建议带业务前缀+权限粒度，例如
org:789:report:update，便于后端按冒号分段提取 org_id 做校验 - 如果用
PSUBSCRIBE（模式订阅），通配符*权限更难收敛，尽量避免；必须用时，只允许在末尾匹配，如user:123:*，禁止*:notify
ACL 能不能直接限制 SUBSCRIBE 行为
Redis ACL（Access Control List）从 6.0 开始支持，但它**不控制频道级订阅权限**，只控制命令执行权和 key 命名空间访问。你可以用 ACL SETUSER 禁掉某个用户执行 SUBSCRIBE，但无法做到「允许 SUBSCRIBE，但只准订 user:123:*」。
实测 ACL 规则如 on >mypass ~user:123:* +subscribe 是无效的——~ 前缀只对 key 操作（如 GET、SET）生效，对 pub/sub 命令无约束力。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
ACL LIST查到的规则里，+subscribe、+psubscribe是开关型权限，开就是全放行，关就是彻底禁用 - 试图用
~channel:*匹配频道名会静默失败，Redis 日志里也不会报错，容易误以为配置生效了 - ACL 唯一能帮上忙的点：给不同业务线分配独立用户，再用
resetkeys防止误操作其他 key 空间，和 pub/sub 权限无关
为什么不能靠 Redis 内置机制做权限路由
因为 Redis pub/sub 的设计目标是轻量广播，不是企业级消息中间件。它的核心数据结构是两个字典：server.pubsub_channels（频道→客户端链表）和 client.pubsub_patterns（模式→客户端链表），没有中间路由层、没有消费者组、不记录消息 ACK，更不支持基于属性的消息过滤。
一旦 PUBLISH 发出，所有已连接且订阅该频道的 client 会**同时、无差别**收到消息——哪怕其中某些 client 已经被业务逻辑判定为“无权查看”。
- 常见错误：前端拿到 token 后自己拼接频道名并调
SUBSCRIBE，后端没做二次校验，导致越权监听 - 更隐蔽的坑：用户登录态过期后，WebSocket 连接未断开，仍持续接收新消息，必须由服务端主动发
UNSUBSCRIBE或关闭连接 - 若需消息审计或重投，得额外引入 Kafka/RocketMQ，Redis pub/sub 不提供消息持久化与回溯能力
实际部署时最容易忽略的兼容性问题
Redis 7.0+ 对 pub/sub 做了连接复用优化，但某些旧版客户端库（如早期 Jedis 3.x、StackExchange.Redis 2.x）在处理 PSUBSCRIBE 多模式时会解析错响应格式，导致订阅失败却无明确异常。
- 务必确认客户端库版本支持 Redis 7 协议，尤其注意
PUBSUB NUMPAT和PUBSUB CHANNELS返回结构变更 - 集群模式（Redis Cluster）下，
PUBLISH只能在单个分片执行，频道名若不含{...}hash tag，可能因路由不一致导致部分订阅者收不到消息 - 生产环境别用
redis-cli --csv SUBSCRIBE channel测试权限逻辑——它不模拟真实客户端心跳与重连行为，容易掩盖连接闪断问题
权限控制这件事，最终落在应用代码里那几行频道白名单校验和连接生命周期管理上。Redis 只负责快和稳地广播，别的都得你自己兜住。
