Redis 6.0 的 ACL 无法单独限制 CONFIG SET maxmemory-policy，因其不解析命令参数，CONFIG SET 作为通用入口，ACL 仅支持命令级而非参数级控制，禁用需依赖配置文件固化、权限隔离等运维手段。
Redis 6.0 中无法通过 ACL 限制用户修改淘汰策略（如 maxmemory-policy），因为所有内存与配置类命令（CONFIG SET、CONFIG GET）都属于 @admin 类别，而 ACL 对 CONFIG 的控制粒度仅到「能否执行」，不支持按配置项细粒度放行或禁止。
为什么 CONFIG SET maxmemory-policy 不能被 ACL 单独限制
ACL 的命令权限基于预定义的类别（ACL CAT 查看）或显式命令名，但 CONFIG SET 是一个通用入口，底层会路由到不同子操作。ACL 不解析其参数内容，所以：
-
+CONFIG或+@admin→ 允许执行任意CONFIG SET xxx yyy，包括maxmemory-policy、maxmemory、save、requirepass等 -
-CONFIG或-@admin→ 完全禁止所有CONFIG相关操作，无法只禁掉淘汰策略却保留CONFIG GET - 不存在类似
+CONFIG_SET_maxmemory-policy这样的细粒度命令名，ACL DSL 不支持参数级匹配
生产环境中真正可行的淘汰策略管控方式
想防止非运维人员误调淘汰策略，必须绕开 ACL 的能力边界，采用组合手段：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 把
CONFIG权限严格保留在运维专用用户（如ops_admin）中，业务用户完全不授予+CONFIG或+@admin - 主节点
redis.conf中**静态配置好maxmemory和maxmemory-policy**，并设为只读文件（如chmod 444 /etc/redis/redis.conf），避免运行时被覆盖 - 禁用
default用户的CONFIG权限：执行ACL SETUSER default -CONFIG -@admin，防止未显式认证的连接滥用 - 若使用容器或编排平台（如 Kubernetes），在启动参数中固化配置，而非依赖运行时
CONFIG SET
验证时容易忽略的关键点
测试淘汰策略权限是否生效，不能只看 ACL GETUSER 输出，必须实测行为：
- 用受限用户连接后执行
CONFIG GET maxmemory-policy→ 若返回NOPERM，说明-CONFIG生效；若返回值，说明该用户仍有+CONFIG - 执行
CONFIG SET maxmemory-policy allkeys-lru→ 成功即代表权限失控，不是 ACL 配置漏了，而是你不该给这个用户+CONFIG -
INFO memory命令属于+@info类别，和淘汰策略无关，不要误以为它能间接暴露或修改策略
ACL 的设计目标从来不是替代配置文件管控，而是隔离数据访问与命令执行。淘汰策略属于实例级运行时配置，它的安全边界在部署层和运维流程里，不在用户命令白名单中。
