好的，没问题。作为一位在Java生态圈深耕多年的资深开发者，今天就来聊聊这个看似简单、实则暗藏玄机的RedisTemplate注入问题。 编写Spring Boot应用时，但凡涉及Redis操作，几乎少不了`RedisTemplate`。然而，正是这个常见的Bean，经常在注入时给你制造麻烦，让你不禁怀疑自己是否写了一个“假”的Spring项目。 先做个总结：大多数注入失败的根本原因，并非Spring容器本身，而在于Java泛型那点“小脾气”。 ### 两种典型的“翻车”现象 * **启动时报错，直接亮红线**：最常见的是`UnsatisfiedDependencyException`，Spring容器明确告知你，找不到类型为`RedisTemplate`的Bean。这通常意味着你定义的Bean与想要注入的类型，在Spring眼中根本不是一回事。 * **IDE标红，但运行“意外”成功**：这种情况更具迷惑性。IDEA中`@Autowired`的位置划了红线，你忐忑地点了启动，业务却居然跑通了。这往往是因为编译器的类型检查比运行时更严格，但泛型擦除这个“障眼法”在运行时给你留了一条生路。不过这绝不代表没有问题，只是运气好，恰好能用。 ### 根源：泛型擦除，一次静态的“偷梁换柱” `RedisTemplate`是一个泛型类，声明为`RedisTemplate`。Spring容器在管理Bean时，是按照**完整类型**进行匹配的，这里的“完整类型”包含了泛型参数。 举个例子，你写`@Autowired RedisTemplate redisTemplate;`，Spring容器就会去寻找一个声明为`RedisTemplate`的Bean。它不会把`RedisTemplate`或未指定泛型的原始类型`RedisTemplate`视为同一个对象。 以下是几个常见的“翻车”场景： * **手动配置Bean，忘记指定泛型**：你在配置类中写`new RedisTemplate()`，没有指定泛型参数。这个Bean在容器中的类型就是`RedisTemplate`。而你注入的地方要求的是`RedisTemplate`，Spring自然不会匹配。 * **配置类返回类型写错**：配置类`@Bean`方法的返回类型如果写成`RedisTemplate`（无泛型），Java编译器会将其视为原始类型。这同样会让Spring在匹配`RedisTemplate`时，认为类型不一致。 * **Lombok或构造注入的陷阱**：使用`@RequiredArgsConstructor`或构造器注入时，如果字段声明的泛型与容器中Bean的泛型不一致，编译时不会报错，运行时却可能抛出`NoUniqueBeanDefinitionException`或注入失败。 ### 正确姿势：三类类型严丝合缝 解决问题的核心只有一条：**配置类Bean的返回类型、注入点的字段类型、以及RedisTemplate内部使用的key/value类型，三者必须完全对齐**。 直接看代码： ```java @Configuration public class RedisConfig { @Bean public RedisTemplate redisTemplate(RedisConnectionFactory factory) { RedisTemplate template = new RedisTemplate<>(); template.setConnectionFactory(factory); template.setKeySerializer(new StringRedisSerializer()); template.setValueSerializer(new StringRedisSerializer()); template.setHashKeySerializer(new StringRedisSerializer()); template.setHashValueSerializer(new StringRedisSerializer()); return template; } } ``` 需要注意的细节： * **字段注入**：` @Autowired private RedisTemplate redisTemplate;`，必须与Bean声明完全一致。 * **杜绝原始类型**：`RedisTemplate`（无泛型）或`RedisTemplate`这类通配符形式，在注入点都要避免，它们非常不可靠。 * **多种序列化策略**：如果你需要同一个Redis操作不同的value格式，比如有的用String，有的用JSON，请不要复用同一个Bean。正确的做法是定义两个不同的Bean，例如`@Bean("stringRedisTemplate") RedisTemplate`和`@Bean("jsonRedisTemplate") RedisTemplate`，并通过`@Qualifier`在注入时精准区分。 ### 容易被忽略的兼容性细节 * `StringRedisTemplate`是“亲儿子”，但不是“万能替身”： Spring Data Redis 3.x之后，`StringRedisTemplate`继承自`RedisTemplate`。但它是一个独立注册的Bean，与你自己配置的`RedisTemplate` Bean是两个东西。不要觉得它“差不多能用”，类型不同，就不能混着注入。 * 序列化器不匹配，数据变乱码： 你用`StringRedisSerializer`设置value，但在存数据前忘记了检查，或使用了默认的JDK序列化，结果就是数据变成一堆无法识别的字节。例如，在`redisTemplate.opsForValue().set("k", "v")`前，务必确认`setValueSerializer`已经设置。 * 连接池与泛型不一致的“静默”问题： 在测试环境使用Lettuce连接池时，如果泛型声明不一致，有时并不会直接报错，而是静默降级到JDK序列化机制。这会引发一个可怕的后果：测试环境一切正常，数据一旦上线生产环境就根本无法读取。这类问题排查起来异常痛苦。 总结一下，处理`RedisTemplate`注入，核心就是“类型对齐”四个字。将泛型声明作为一等公民来对待，就能规避绝大多数问题。