@cacheevict失效主因是cachename或key不匹配，需严格一致；beforeinvocation=false时异常导致跳过清除；allentries=true易引发雪崩，应慎用。
CacheName不匹配导致@CacheEvict完全无响应
缓存名称（value）必须与@Cacheable中声明的完全一致，包括大小写、空格、冒号等字符。Spring不会做任何模糊匹配或自动归一化处理。
常见错误现象：日志里看不到任何缓存操作记录，Redis中对应key依然存在，且@CacheEvict方法已正常执行。
-
@Cacheable(value = "user:info")和@CacheEvict(value = "user_info")→ 不匹配 -
@Cacheable(cacheNames = {"users"})与@CacheEvict(value = "users")→ 匹配（cacheNames和value语义等价） - 多个缓存名时，
@CacheEvict只清除列表中明确列出的那些，不会“继承”或“推断”其他缓存名
Key生成逻辑不一致是失效最常见原因
默认情况下，@Cacheable和@CacheEvict都使用SimpleKeyGenerator：若方法有多个参数，会生成类似SimpleKey [1001, "ACTIVE"]这样的key；若无参，则是SimpleKey.EMPTY。只要两边key生成规则不同，就永远删不掉。
典型场景：一个接口有两个@RequestParam，但@CacheEvict没写key属性，而@Cacheable用了key = "#id" —— 两者根本对不上。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 统一方案：所有缓存操作都显式指定
key，例如key = "#subWarehouseId + '_' + #warehouseId" - 避免依赖默认行为：哪怕只有一个参数，也建议写
key = "#id"，防止后续加参后崩掉 - 对象参数慎用
#user.id：若user为null，SpEL会抛EvaluationException，导致整个清除跳过（不报错，静默失败）
beforeInvocation=false时方法异常会导致清除被跳过
默认beforeInvocation = false，意味着缓存清除动作在方法体执行**成功后**才触发。一旦userRepository.deleteById(id)抛出异常（如数据库连接超时、主键不存在），@CacheEvict就不会执行。
这不是bug，而是设计行为——Spring认为“操作没成功，就不该动缓存”。但业务上往往需要“先清缓存，再删库”，否则容易出现脏读。
- 修复方式：设
beforeInvocation = true，让清除提前到方法执行前 - 副作用：即使数据库删除失败，缓存也已被清空，需配合重试或补偿机制
- 注意：此时
condition表达式能访问的参数仅限入参，不能用#result（因为还没执行）
allEntries=true看似简单，实则埋雷
启用allEntries = true确实能绕过key匹配问题，但它会清空整个缓存区域，不是“删错”，而是“删过头”。
生产环境高频调用它，极易引发缓存雪崩：大量请求瞬间穿透到DB，CPU和连接数飙升。
- 仅适用于低频、可控场景，如定时刷新字典表缓存
- 绝不应在用户请求链路中直接使用（比如HTTP接口里调用
@CacheEvict(allEntries=true)） - 如果真需要前缀批量删，应自定义注解（如
@CacheRemove(pattern = "user:*")）+ AOP + RedisSCAN，而不是滥用allEntries
@CacheEvict的key和@Cacheable的key必须出自同一套生成逻辑，差一个字符、多一个括号，就等于没写。
