redistemplate默认使用jdkserializationredisserializer导致乱码、跨语言不互通及notserializableexception；必须替换为jackson2jsonredisserializer并显式指定类型反序列化，否则取值为linkedhashmap。

RedisTemplate 默认用 JDK 序列化，存进去全是乱码，直接上线会出问题。必须替换为 JSON 序列化，否则连调试都困难。

为什么不能直接用默认的 RedisTemplate

Spring Boot 自动配置的 RedisTemplate 使用 JdkSerializationRedisSerializer，序列化后 key 和 value 都是二进制字节流，Redis CLI 里看到的是类似 \xac\xed\x00\x05t\x00\x03foo 的内容，根本没法人工排查、无法被其他语言服务消费、也不支持跨版本反序列化。

• JSON 序列化能让数据可读、可调试、可协作（比如前端或 Python 服务也能读）
• 必须同时设置 keySerializer（用 StringRedisSerializer）和 valueSerializer（用 GenericJackson2JsonRedisSerializer 或自定义 Jackson2JsonRedisSerializer）
• 如果业务含 Java 8 时间类型（LocalDateTime 等），需额外注册 Jackson2ObjectMapperBuilder 并引入 jackson-datatype-jsr310 依赖

@Cacheable 注解缓存 null 值会导致穿透风险

Spring Cache 默认允许缓存 null 返回值，一旦数据库查不到数据，@Cacheable 就把 null 写进 Redis —— 下次请求照样击中缓存，永远绕不开 DB，形成缓存穿透。

Spring Boot Actuator Analyzer

分析Spring Boot Actuator端点的安全性、健康检查、指标暴露及生产配置——审计信息、健康状态和自定义端点。

下载

• 在 CacheManager 配置里显式调用 .disableCachingNullValues()
• 搭配布隆过滤器（Bloom Filter）或空对象（如 "empty" 字符串）做兜底，但注意避免误判和内存膨胀
• 不要依赖 @Cacheable(unless = "#result == null")，它只跳过写入，不阻止首次缓存 null（取决于执行顺序）

Lettuce 连接池参数配错会拖垮整个应用

默认的 Lettuce 连接池（max-active: 8、max-wait: -1ms）在高并发下极易卡死：-1 表示无限等待，线程全堵在 getConnection() 上，HTTP 请求超时、线程耗尽、雪崩一气呵成。

• max-wait 必须设为有限值（如 100ms），超时抛异常比无限挂起更可控
• min-idle 设为非 0（如 2），避免冷启动时连接建立延迟
• max-active 不宜盲目调大（如 >32），Lettuce 是基于 Netty 的异步客户端，连接数过多反而增加调度开销
• 线上建议配合 lettuce: shutdown-timeout: 100ms 防止应用停机时连接泄漏

缓存失效策略选错，一致性很难兜住

用 @CacheEvict 删除缓存看似简单，但在分布式环境下，多个实例同时更新 DB + 同时删缓存，大概率出现“先删缓存、再改 DB”期间的脏读；或者“改 DB 成功、删缓存失败”导致永久不一致。

• 优先用「先更新 DB，再删除缓存」+ 最终一致性补偿（如监听 binlog 或发 MQ 消息异步删）
• 避免用「更新缓存」代替「删除缓存」，除非你能保证所有写路径都覆盖且无并发冲突
• 对强一致性要求高的场景（如账户余额），别走缓存，直接查 DB + 加行锁或乐观锁

实际最易被忽略的点是：缓存键设计没加业务前缀，不同环境（dev/test/prod）共用一个 Redis 实例时，测试数据会污染生产缓存；或者不同微服务用相同 key 名，互相覆盖。这事不会报错，但会让问题变得极其隐蔽。