Redis 6.0 ACL频道权限需同时满足&pattern匹配和显式授予+SUBSCRIBE等Pub/Sub命令，仅配&metrics或仅授+@read均无效；~不作用于频道，&才匹配频道名，且必须ACL SAVE到aclfile并正确配置路径才能持久化。
Redis 6.0 的 ACL **不能按频道名做白名单/黑名单式控制**，但能通过 & pattern + Pub/Sub 命令权限的双重校验，实现“频道范围 + 操作能力”的组合限制。只配 &metrics 不给 +SUBSCRIBE，或只给 +@read 却漏掉 +@pubsub，都会导致 SUBSCRIBE 直接报 (error) NOPERM。
为什么 &metrics 却收不到消息？——搞混 key 和 channel 的匹配机制
常见错误是把 ~（键匹配）和 &（频道匹配）当一回事用。比如写 ~metrics，这根本不管用：Redis 中 key 和 channel 是两套独立路径，~ 只影响 GET、DEL 等键操作，对 SUBSCRIBE metrics 完全无约束。
真正生效的是 & 后的 glob 模式，且必须配合 Pub/Sub 命令权限才起作用：
-
&metrics匹配频道名metrics，不匹配metrics:cpu（除非写成&metrics:*） -
&logs:[0-9]匹配logs:5，但不匹配logs:12（因为[0-9]只匹配单字符） -
&*允许所有频道，但若没授+SUBSCRIBE，照样连不上任何频道
ACL SETUSER 配频道权限时，必须同时满足两个条件
频道访问不是“开了 pattern 就通”，而是「频道名匹配」+「命令许可」双闸门同时打开才行。漏掉任一环节，SUBSCRIBE 就失败。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 频道 pattern 必须用
&开头，例如&order:*，不能写成~order:* - 必须显式授予至少一个 Pub/Sub 命令：
+SUBSCRIBE、+PSUBSCRIBE、+PUBLISH；+@read或+@all不自动包含它们 - 如果用户要
UNSUBSCRIBE，得额外加+UNSUBSCRIBE（+@pubsub里不包含它） - 发布消息也受
&限制：即使有+PUBLISH，若频道名不匹配&pattern，PUBLISH同样被拒
典型安全配置示例与验证要点
比如为监控账号限定只订阅 metrics:*、只读 audit:* 键：
ACL SETUSER monitor on >mon123 ~audit:* &metrics:* +SUBSCRIBE +PSUBSCRIBE +@read
验证时别只看 ACL GETUSER monitor 输出，要实连实测：
- 用
redis-cli -u redis://monitor:mon123@127.0.0.1:6379连接 -
SUBSCRIBE metrics:cpu→ 应成功（匹配&metrics:*且有+SUBSCRIBE） -
SUBSCRIBE system:load→ 报NOPERM（不匹配&metrics:*） -
GET audit:status→ 成功（匹配~audit:*且有+@read） -
PUBLISH metrics:cpu "1.2"→ 报NOPERM（没授+PUBLISH）
持久化时最容易被忽略的两个点
ACL SAVE 不会自动写进 redis.conf，它只覆盖 aclfile 配置项指定的文件（默认是 users.acl）。如果 redis.conf 里没配 aclfile /etc/redis/users.acl，或者 Redis 进程对那个路径不可写，ACL SAVE 会静默失败——重启后权限全丢。
另一个易漏点：ACL WHOAMI 必须在认证后执行，未 AUTH 时永远返回 "default"，所有操作都走 default 用户权限，根本测不出你刚设的用户规则。
