@cacheable不生效需检查三件事：未启用@enablecaching、方法非public、同类内直接调用绕过代理；@cacheevict key不一致会导致删错缓存；redis缓存需配置rediscachemanager并确保对象可序列化。
@Cacheable 不生效？检查这三件事
缓存没走、方法反复执行、@Cacheable 像摆设——八成是配置或用法踩了坑。
- 没开缓存开关：
@EnableCaching必须加在某个@Configuration类上，光加注解不启用等于没装发动机 - 方法不是 public：Spring AOP 代理只拦截 public 方法，private/protected 方法加
@Cacheable直接被忽略 - 调用发生在同一个类内：比如 A 方法加了
@Cacheable，B 方法直接this.A()调用，绕过了代理，缓存失效
验证是否生效最简单的方式：加个日志，或者在被缓存方法里打个断点，看第二次请求还进不进去。
@CacheEvict 删除缓存时 key 对不上怎么办
删了缓存但下次查还是旧数据，大概率是 @CacheEvict 的 key 和 @Cacheable 不一致，导致删的不是同一份缓存。
- 别依赖默认 key：默认 key 是参数列表，但对象参数会用
toString()，很可能生成一串无意义哈希值；建议显式写key = "#id"或key = "#user.id" - 注意 SpEL 表达式语法：如果参数是
Long id，写key = "#id"；如果是User user，写key = "#user.id"；别漏掉#，否则就是字面量字符串 - 批量删除慎用
allEntries = true：它清空整个 cacheName，高并发下可能引发缓存雪崩，优先考虑精准 key 删除
示例：@CacheEvict(value = "user", key = "#id") 比 @CacheEvict(value = "user", allEntries = true) 更可控。
多级缓存场景下 @Cacheable 与 Redis 配合的常见陷阱
用了 Redis 做缓存，但 @Cacheable 还是走本地 HashMap，或者序列化失败报 NotSerializableException。
- 确认 CacheManager 类型：Spring Boot 自动配置的是
ConcurrentMapCacheManager（内存），要换成RedisCacheManager，得引入spring-boot-starter-data-redis并确保 Redis 连接正常 - 对象必须可序列化：Redis 缓存默认用
JdkSerializationRedisSerializer，要求返回值类型实现Serializable；更推荐配GenericJackson2JsonRedisSerializer，避免序列化限制 - 缓存穿透风险：
@Cacheable默认不缓存null，查不到就反复打 DB；可加unless = "#result == null"或配合@Cacheable(..., condition = "#id != null")控制
检查当前生效的 CacheManager：启动日志搜 CacheManager，看到 RedisCacheManager 才算接上了 Redis。
缓存一致性难维护？先想清楚“谁负责写”
一个用户信息被多个接口更新，@CacheEvict 散落在不同 Service 方法里，很快就会漏删、错删、重复删。
- 写操作和缓存清理必须绑定在同一事务边界：用
@Transactional包住数据库更新 +@CacheEvict，否则 DB 提交失败但缓存已删，状态就乱了 - 避免“读时刷新”：不要在
@Cacheable方法里手动查 DB 再塞缓存，那是侵入式缓存，违背声明式初衷 - 复杂更新逻辑建议封装为独立服务：比如
UserCacheService.refreshById(Long id)，统一触发 DB 更新 + 多级缓存清理，比到处写@CacheEvict更可靠
真正麻烦的从来不是怎么加注解，而是当业务变复杂、缓存层级变多、更新入口变分散时，没人再能一眼看清“这条数据到底该什么时候删”。
