acl无法单独禁用flushall和keys，因flushall默认未归入@dangerous组、keys属于@read组，且acl仅对“存在”的命令生效；而rename-command flushall ""可彻底屏蔽命令，优先级高于acl，必须在redis.conf security区域后配置并重启生效。
Redis集群模式下，仅靠 ACL 配置无法真正禁用 FLUSHALL、KEYS 等命令——必须在每个节点的 redis.conf 中显式配置 rename-command，否则存在绕过风险。
为什么 ACL 不能单独禁用 FLUSHALL 和 KEYS
ACL 的 -@dangerous 组默认不包含 FLUSHALL（多数 Redis 6.0–7.0 发行版未将其归入该组），而 KEYS 属于 @read 组，删它等于禁掉所有读操作。验证方式是执行 redis-cli ACL CAT dangerous，你会发现 FLUSHALL 常缺席、KEYS 从不在其中。ACL 对未显式授权的命令默认拒绝，但前提是命令名“存在”；一旦 rename-command FLUSHALL "" 生效，ACL 根本收不到这个命令，也就无从拦截。
必须在 redis.conf 中配置 rename-command
rename-command 是唯一能彻底屏蔽命令的机制，且优先级高于 ACL。关键点包括：
- 配置必须写在
redis.conf的# SECURITY区域之后，否则可能被后续默认配置覆盖 - 常见翻车点：用了
include /etc/redis/conf.d/*.conf，但主 conf 没写rename-command，而子 conf 里写了两次，后一次覆盖前一次 - 配置路径容易被忽略：Docker 启动时挂载了旧配置，或手动运行
redis-server /tmp/custom.conf却忘了更新路径 - 必须重启进程才生效，
CONFIG REWRITE不支持rename-command
推荐配置（放在 SECURITY 区域下方）：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
rename-command FLUSHALL "" rename-command FLUSHDB "" rename-command CONFIG "" rename-command KEYS "" rename-command SHUTDOWN "" rename-command DEBUG ""
集群环境下所有节点必须统一配置
Redis Cluster 不同步 rename-command 配置，每个 shard、每个 Sentinel、每个 Proxy（如 Codis 或 Twemproxy）都得单独改。漏掉一个节点，就等于留了一扇没锁的门。确认是否生效最靠谱的方式是连接节点后执行：
redis-cli CONFIG GET rename-command
返回结果中必须看到类似 "flushall" "" 的键值对；如果为空或没这项，说明配置根本没加载。生产环境建议配合 ACL 创建低权账号（如 ACL SETUSER app -@all +get +set +incr），让应用只连这个账号。
禁用后如何替代常用操作
KEYS * 被禁后，可用 SCAN 替代，例如：
SCAN 0 MATCH user:* COUNT 1000
FLUSHDB 被禁后，若真需清空单库，应走运维审批流程，使用重命名后的高危命令（如 rename-command FLUSHDB "admin_flushdb_2026"），而非开放原名。不要依赖 save "" 来“禁用 FLUSHALL”——那是误传，save 控制的是 RDB 持久化触发条件，和 FLUSHALL 无关。
