Redis 6.0引入ACL是为解决旧版单密码机制下权限无法隔离的根本问题：一个密码即拥有所有命令、所有键、所有数据库的完全控制权；ACL通过用户粒度的三要素（启用状态on、有效密码、显式命令权限）和glob风格键模式（~pattern），实现命令与键空间的精细化、可持久化（ACL SAVE需aclfile路径正确且可写）权限分离管控。
Redis 6.0 引入 ACL 不是为了“增强功能”，而是为了解决旧版单密码机制下根本无法隔离权限的现实问题：一个密码 = 所有命令 + 所有键 + 所有数据库。只要拿到密码，就能执行 FLUSHALL、KEYS *、DEBUG SEGFAULT，甚至订阅任意 Pub/Sub 频道。
这在多租户、微服务共用 Redis 实例的场景中极其危险——项目 A 的缓存键 user:123 和项目 B 的敏感数据 payment:txn_456 存在同一实例里，却共享同一套认证凭证。
ACL 的核心价值，是把「谁可以运行什么命令」「谁可以读写哪些键」这两件事，真正拆开控制，落到具体用户粒度。
ACL 用户权限由三部分组成，缺一不可
一个用户要能正常工作，必须同时满足以下三项配置，否则连接成功但命令被拒：
-
on：用户状态必须启用（off状态下即使密码正确也拒绝认证） - 至少一个有效密码：
>password（明文）或#hash（SHA256 哈希），不能只写nopass（除非你明确允许无密登录） - 显式授予命令权限：
+@read、+get、+@all等；默认新建用户是-@all（全拒）
例如，只执行 ACL SETUSER alice on >p1pp0，用户 alice 仍无法执行任何命令——因为没给命令权限。必须补上 +@read 或类似规则。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
键权限（~pattern）不是通配符补丁，而是正则匹配引擎
~pattern）不是通配符补丁，而是正则匹配引擎ACL 的键模式用 ~ 前缀，底层是 glob 风格匹配（非完整正则），但支持常见通配：
-
~user:*→ 匹配user:1、user:profile:abc -
~order/202[4-6]/*→ 匹配order/2025/123，但不匹配order/2023/456 -
~*→ 允许所有键（等价于旧版行为） -
~cache:img:* ~cache:json:*→ 多个模式需分开写，用空格分隔
注意：KEYS * 这类扫描命令本身受命令权限控制；即使有 ~* 键权限，若未授予 +keys，该命令仍被拒绝。键权限只约束「对已知键的操作」，不自动放开元操作。
ACL SAVE 不等于“永久生效”，它依赖 redis.conf 可写且路径正确
ACL SAVE 不等于“永久生效”，它依赖 redis.conf 可写且路径正确运行时执行的 ACL SETUSER 只驻留在内存。重启后丢失，除非调用 ACL SAVE。但它不是写进任意文件，而是覆盖 redis.conf 中的 aclfile 指定路径（默认是 users.acl，而非主配置文件本身）。
- 若 redis.conf 里没配
aclfile /etc/redis/users.acl，ACL SAVE会静默失败（返回 OK 但实际没保存） - 若
/etc/redis/目录 Redis 进程无写权限，ACL SAVE报错：(error) ERR Error writing ACL file: Permission denied - 修改后必须确保
aclfile路径在redis.conf中存在且可写，再ACL SAVE，最后CONFIG REWRITE（可选）或重启验证
最容易被忽略的一点：很多部署直接用容器或 systemd 启动，redis.conf 往往挂载为只读，ACL SAVE 看似成功，实则落盘失败——下次重启就回到初始状态。
