redis 6.x 的 acl 不能预防缓存穿透，仅控制命令执行权限和 key 名称模式匹配，不校验 key 是否真实存在或业务合法性，防穿透需依赖空值缓存、布隆过滤器、参数校验等应用层机制。
Redis 6.x 的 ACL 权限控制本身不能预防缓存穿透，更无法限制“非法 Key 查询”——因为 ACL 根本不干预 key 是否存在、是否合法，它只控制用户能否执行某个命令、能否访问匹配某模式的 key。
ACL 对 key 的控制仅作用于命令执行阶段，而非查询语义判断
ACL 的 ~pattern 规则（如 ~user:* ）只在用户调用命令（如 GET、DEL、HGETALL）时做一次前缀匹配校验。它不检查 key 是否真实存在，也不拦截 GET nonexist:key 这类操作——只要 key 名字符合模式，命令就放行；哪怕该 key 从未写入过，ACL 也完全不管。
常见误解场景：
- 以为配置了
ACL SETUSER app on >app123 ~order:* +@read就能阻止查user:999——实际无效，ACL 不校验 key 内容合法性，只看名字是否匹配~order:* - 试图用 ACL 阻止
KEYS *扫描不存在的 key ——正确做法是禁用该命令（-keys），但这是防阻塞，不是防穿透
真正能缓解穿透的机制和 ACL 完全无关
缓存穿透本质是“查询一个数据库里也不存在的 key”，而 Redis 作为缓存层，对 key 是否在后端存在毫无感知。应对方式必须落在应用层或架构层：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
SETEX nonexist:user:123 "" 300：空值缓存，靠业务代码显式写入，ACL 不参与 - 布隆过滤器预检：部署在客户端或网关，拦截明显非法 ID（如负数、超长字符串），Redis 本身不运行布隆逻辑
- 参数白名单校验：在 API 入口校验 user_id 是否符合正则或范围，未进 Redis 就拒绝
ACL 甚至可能让穿透更隐蔽：如果给监控账号开了 +get 但没配 ~*，反而导致 GET 调用直接报错（(error) NOPERM），掩盖了穿透行为本身。
ACL 唯一相关的作用：防止穿透演变成误删或越权访问
当穿透发生后，如果攻击者或缺陷代码顺手执行了危险操作，ACL 才体现价值：
- 禁止非运维账号使用
FLUSHDB或CONFIG REWRITE，避免穿透引发的连锁误操作 - 限制开发账号只能读写
~cache:*，即使穿透请求被错误地发往 Redis，也无法碰触~session:*或~config:*等敏感 key 空间 - 关闭
default用户的+@all，强制所有连接显式认证，让穿透流量至少带上可追溯的用户名
也就是说，ACL 不拦“查不存在的 key”，但它能确保“查完之后干不了别的坏事”。这点容易被文档话术带偏——看到“key pattern control”就以为能过滤 key 语义，其实只是字符串前缀匹配。
真正要防穿透，得在 Redis 之外下功夫；ACL 做好权限隔离，就已经尽到本职了。
