ACL中&控制频道匹配、~控制键匹配，仅设&metrics但未授权+@pubsub或+SUBSCRIBE会导致SUBSCRIBE失败；必须同时满足频道pattern匹配和Pub/Sub命令权限。
直接说结论：用 ACL SETUSER 的 <pattern> 语法限制 Pub/Sub 频道访问，但必须配合 +@pubsub 或具体命令（如 +PSUBSCRIBE）才生效，否则连 SUBSCRIBE 都会被拒。
为什么 &metrics 却收不到消息？
常见错误是只写 ~metrics —— 这个波浪号只管键（key），对频道（channel）完全无效。Redis 中 key 和 channel 是两套独立的匹配机制：~ 控制 key，& 才控制 channel。
典型失败配置：
ACL SETUSER monitor on >mon123 ~* &metrics +@read
这段配置看似限制了频道，实际运行时执行 SUBSCRIBE metrics 会报错：(error) NOPERM this user has no permissions to access one of the channels。因为 +@read 不包含任何 Pub/Sub 命令。
必须显式授权 Pub/Sub 相关命令，且 & 后的 pattern 必须能匹配实际订阅的频道名（支持 glob 通配符，如 &metrics:* ）。
& 频道模式和 +/- 命令权限怎么配才不漏？
频道权限不是“开了就通”，而是「频道匹配 + 命令许可」双条件同时满足。容易踩的坑包括：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
&*允许所有频道，但若没给+SUBSCRIBE或+@pubsub，照样无法订阅 -
&logs:*只匹配logs:error、logs:info，不匹配logs（无冒号）或app:logs（前缀不符） -
+@pubsub包含SUBSCRIBE、PSUBSCRIBE、PUBLISH等，但不含UNSUBSCRIBE；如需退订，得额外加+UNSUBSCRIBE - 如果用户需要发布消息，除了
+PUBLISH，还必须确保其有对应频道的&<pattern>权限（发布也受频道 pattern 限制）
安全推荐组合（只读监控场景）：
ACL SETUSER auditor on >aud123 ~audit:* &metrics:* +SUBSCRIBE +PSUBSCRIBE +@read
验证频道权限是否真生效？
别只信 ACL GETUSER 输出，要实测连接行为：
- 用新用户连接：
redis-cli -u redis://auditor:aud123@127.0.0.1:6379 - 执行
SUBSCRIBE metrics:cpu→ 应成功（匹配&metrics:*） - 执行
SUBSCRIBE system:load→ 应报NOPERM（不匹配&metrics:*） - 执行
GET audit:status→ 应成功（匹配~audit:*且有+@read） - 执行
DEL audit:status→ 应报NOPERM（+@read不含DEL）
注意：ACL WHOAMI 要在认证后执行，否则返回 "default"；未认证状态下所有操作都走 default 用户权限。
持久化频道权限时最容易丢的两个点
ACL SAVE 不会自动重写 aclfile 路径下的文件，除非你在 redis.conf 明确配置了 aclfile 且 Redis 进程对其有写权限。
- 检查
redis.conf是否含aclfile /etc/redis/users.acl，路径必须是绝对路径 - 确认 Redis 进程用户（如
redis）对该文件有写权限：ls -l /etc/redis/users.acl - 执行
ACL SAVE后，手动cat /etc/redis/users.acl确认内容已更新，尤其检查&行是否存在 - 重启前务必
ACL LOAD测试加载是否成功，避免因语法错误导致启动失败
真正上线前，建议把 & pattern 和 key pattern 分开测试——频道权限失效往往静默发生，直到业务方反馈消息收不到，才暴露问题。
