@CacheEvict未清除Redis缓存主因是CacheName或key不匹配、未走AOP代理、key前缀未手动拼接、beforeInvocation=false时异常跳过，或allEntries=true在带前缀场景下SCAN失败。
@CacheEvict没删掉Redis缓存，基本可以断定是key没对上，或者压根没走到代理方法里——不是Redis连不上，也不是注解写错了，而是Spring根本没执行清除逻辑。
CacheName和key必须完全一致，大小写、冒号、空格都不能差
Spring不做任何归一化或模糊匹配。比如：@Cacheable(value = "user:info", key = "#id") 和 @CacheEvict(value = "user_info", key = "#id") 就完全不匹配，缓存不会被删，日志也静默无输出。
-
cacheNames和value是等价的，但必须字面完全相同；多个缓存名时，@CacheEvict只清列表里明确写出的那些 - 如果用了 Redis Key 前缀（如
spring.cache.redis.key-prefix=app:），这个前缀只影响@Cacheable写入的 key，@CacheEvict的key表达式里**不自动加前缀**，你得自己拼：例如key = "'app:user:' + #id" - 检查 Redis 里实际存的 key 是什么（用
redis-cli执行SCAN 0 MATCH *user*），再反推你的@CacheEvict是否能生成一模一样的字符串
方法没走 Spring AOP 代理，@CacheEvict 根本不触发
这是最隐蔽也最常被忽略的问题：内部调用、非 Spring 管理的 Bean、private 方法、final 方法，都会导致代理失效。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Service 类中 A 方法加了
@CacheEvict，B 方法直接调用this.A()→ 不走代理，注解无效 - Controller 直接 new 出 Service 实例调用 → 没进 Spring 容器，AOP 失效
- 方法返回值不是
void且没配beforeInvocation = true，默认会在方法成功后执行清除；一旦抛异常，清除就被跳过 - 验证方式：在方法入口打个断点，看调用栈里有没有
CacheInterceptor或CacheAspectSupport
key 生成逻辑两边不统一，尤其是多参数或对象参数
默认 SimpleKeyGenerator 对两个参数会生成 SimpleKey [1001, "ACTIVE"] 这种结构，而你 @Cacheable 里写了 key = "#id"，两边 key 根本不是同一个东西。
- 只要
@Cacheable显式写了key，@CacheEvict就必须写一模一样的表达式，不能依赖默认行为 - 对象参数慎用
#user.id：若user == null，SpEL 抛EvaluationException，清除静默失败（不报错，也不删） - 推荐统一写法：哪怕只有一个参数，也显式写
key = "#id"；两个以上参数时，拼成字符串，例如key = "#subWarehouseId + '_' + #warehouseId"
allEntries = true 在带前缀的 Redis 部署下可能失效
当 Redis 配置了全局 key 前缀（比如通过 RedisCacheConfiguration 设置了 keyPrefix），allEntries = true 调用的是 RedisCacheWriter.clean()，但它传给底层 SCAN 命令的 pattern 默认不含前缀，结果扫不到任何 key。
- 现象：日志显示 “Cleared cache ‘users’”，但 Redis 里对应前缀的 key 一个没少
- 这不是 bug，是设计限制：Spring Cache 的
clean()不感知业务层 key 序列化逻辑 - 临时绕过：改用
redisTemplate.keys("your-prefix:user:*")+redisTemplate.delete(...)，但注意KEYS禁止在生产用，务必换成SCAN分批处理 - 长期方案：自定义
RedisCacheWriter代理，在clean()中手动补上前缀
真正难排查的从来不是“怎么写”，而是“为什么看起来写了却没执行”——关键要确认那条清除指令是否真的发到了 Redis，而不是卡在代理、key 匹配或事务上下文销毁的半路上。
