缓存键清理失败主因是代码键名与redis实际键名不一致，需逐层排查键生成、序列化、存储、扫描四环节，重点检查前缀差异、scan模式合规性、spring cache键生成逻辑及客户端/代理层转换。
缓存键清理工具无法匹配统配键，本质是“你认为的键”和“Redis里真实存在的键”不一致。排查要从键生成、序列化、存储、扫描四个环节逐层验证，而不是盲目重试KEYS或SCAN命令。
确认实际存储的键名是否带预期前缀
很多清理失败的根源在于：代码里写的"user:profile:1001"，Redis里存的却是"cache::user:profile:1001"甚至"myapp:user:profile:1001"——多了一层自动拼接的前缀。
- 用
redis-cli --scan --pattern "*profile*"列出所有疑似键，人工检查前缀是否多出、少掉或格式错位（比如user_profile:1001vsuser:profile:1001） - 在应用日志中开启缓存操作全量记录，搜索
Cache put key=或set key=，直接看到写入时的真实键名 - 如果用了
RedisTemplate自定义KeySerializer，重点检查serialize()方法是否重复加前缀（常见错误：deserialize也加前缀，导致读取时键被二次修饰）
验证SCAN模式是否语法合规
SCAN不支持KEYS那种shell通配符（如user:*），它用的是glob风格匹配，且对特殊字符敏感。
- 确保模式中没有空格、换行或不可见字符；
"user:profile:*"合法，但"user:profile: *"（冒号后多空格）就完全不匹配 - 若键中含点号、中划线、下划线等，需确认是否被转义；例如
"user.v1:profile:*"必须写成"user\.v1:profile:*"才可靠（取决于Redis版本和客户端） - 用
SCAN 0 MATCH "user:profile:*" COUNT 100手动执行，观察游标返回结果是否为空；如果空，说明模式本身就没命中
检查Spring Cache抽象层是否隐式改写了键
@CacheEvict或@Cacheable底层可能通过KeyGenerator生成了与直觉不符的key，尤其当没显式指定key属性时。
- 对比
@Cacheable(key = "#id")和@CacheEvict(key = "#id")——两边必须完全一致；若一个写了key = "#userId"另一个没写，就默认走SimpleKey，必然不匹配 - 对象参数慎用
#user.id：一旦user为null，SpEL静默失败，key变成SimpleKey.EMPTY，而缓存里存的是SimpleKey [1001]，永远对不上 - 启用Spring Cache调试日志：
logging.level.org.springframework.cache=DEBUG，看日志里打印的Computed cache key是否和你预期一致
排除客户端/代理层的键名转换
某些Redis客户端（如Lettuce）、中间件（如Twemproxy、Redisson）、或云厂商代理（如阿里云Tair Proxy）会在传输过程中重写key。
- 绕过所有中间层，直接用
redis-cli -h your-redis-host -p 6379连真实实例，执行SCAN验证原始数据 - 查看客户端配置：Lettuce是否启用了
CommandLatencyCollector或自定义CommandOutput；Redisson是否配置了codec影响key序列化 - 云环境特别注意：部分托管服务会强制添加命名空间前缀（如
ns_12345:user:profile:1001），需在清理脚本中补上
