一个必须前置的硬性前提：你的Redis必须升级到6.0+版本，否则ACL这套权限体系根本不起作用，连ACL这个命令都找不到。
顺便说一句，哪怕是升级到了6.0，default用户默认也是权限全开的，这一点很容易被忽略。
确认版本和默认用户权限是否已实际生效
先用redis-server --version确认版本号，输出必须是Redis server v=6.0.0或更高才行。低于这个版本，执行ACL SETUSER只会收到一个神秘的ERR unknown command `ACL`。启动之后，建议立刻跑一遍ACL LIST，你会看到类似user default on nopass ~* &* +@all这样的输出——这代表ACL模块虽然启动了，但default用户依旧拥有“上帝视角”，没有任何权限隔离。这时候，就算你辛辛苦苦创建了其他用户，只要客户端没有显式地用AUTH切换身份，所有操作还是走default用户，权限配置形同虚设。
按业务边界建模用户，严格绑定key pattern
ACL的~规则只支持glob模式匹配（比如~order:*），不支持正则表达式或通配符叠加。这意味着你没法用一个用户覆盖所有业务前缀，必须把不同业务拆分成独立的用户：
订单服务用户：权限限定在
~order:*，只开放+@sortedset +@string，同时要禁用-FLUSHDB -KEYS这样的高危命令。用户服务用户：权限限定在
~user:*，开放+@hash +@string，禁用-CONFIG -DEBUG。监控账号：只读权限，使用
+@read ~monitor:*，并且显式剔除-CLIENT -INFO，以防暴露连接细节。
键模式这个细节非常关键。如果写成了~order而不是~order:*，那么这个用户将无法命中任何key，所有命令都会返回NOPERM，而且没有任何明确的错误提示。排查问题时，你可能会在权限判断环节卡很久，得特别注意。
命令权限顺序决定最终效果，避免+@category -command陷阱
ACL权限的生效规则是按命令输入顺序“最后一条生效”。但这里有个隐藏的坑：+@write这类类别内部已经预置了子命令列表，如果你在后面加一条-SET，它并不会覆盖类别中的SET权限。正确的做法是：
优先用细粒度列举：比如
+GET +HGETALL +ZADD -FLUSHALL -KEYS -DEBUG。这样每个命令的权限都清清楚楚，不容易出错。如果实在要用类别，务必确认
-command位于+@category之后，并且确认这个命令确实属于该类别（可以通过ACL CAT @write来查）。+@all是高危操作，即使后面加个-FLUSHALL，也很可能漏掉一些未归类的子命令，比如某些模块扩展的命令。建议尽量避免使用。
测试时别只看命令输入的顺序，一定要用ACL GETUSER 查看commands字段的实际生效值。这个字段才是客户端真正拿到的权限快照。
客户端连接必须显式传用户名，旧版AUTH不兼容
Redis 6.0的AUTH命令已经从单参数升级为双参数：AUTH 。如果代码里还使用旧版的AUTH ，连接会悄悄fallback到default用户，你辛辛苦苦配置的ACL等于完全白费。生产环境中，这个环节是最容易被忽视的。
几个常见客户端配置要点：
Spring Data Redis：默认不传用户名，需要显式配置
spring.redis.username=order_svc。Node.js的ioredis：需要在构造选项中加上
username: 'order_svc'。Python的redis-py：只有6.0+版本才支持
username参数，旧版本会报TypeError。
简单说：权限配置得再严，只要客户端没切到正确的用户，所有操作还是发生在default用户的全权上下文里。这是最容易被忽略，也最容易捅娄子的环节。
