stringredisserializer可避免乱码和体积膨胀，因其直接使用utf-8编码字符串；而jdkserializationredisserializer会将字符串序列化为含类信息的二进制，导致redis中显示乱码且存储体积显著增大。
直接用 StringRedisSerializer，别碰 JdkSerializationRedisSerializer —— 后者会把字符串也序列成带类信息的二进制，体积翻倍还不可读。
为什么 String 类型还要专门配序列化器？
因为 RedisTemplate 默认对 value 用的是 JdkSerializationRedisSerializer，哪怕你存的是纯字符串（比如 "hello"），它也会包装成 java.lang.String 的完整序列化字节流，开头一堆杂项标记，实际 Redis 里看到的是类似 aced0005737200116a6176612e6c616e672e537472696e67... 这样的乱码。
这不是 bug，是默认行为：Spring Data Redis 把 Object 当通用容器，不区分原始类型。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 存
"abc"用 JDK 序列化 → 约 80+ 字节 - 存
"abc"用StringRedisSerializer→ 就是 3 字节 UTF-8 编码 - Key 不配的话，
opsForValue().set("user:1001", "jack")中的"user:1001"也会被 JDK 序列化，浪费空间
怎么配 StringRedisSerializer 给 key 和 value？
在 RedisConfig 里显式指定，且必须调用 afterPropertiesSet()，否则配置不生效：
@Bean
public RedisTemplate<string string> redisTemplate(RedisConnectionFactory factory) {
RedisTemplate<string string> template = new RedisTemplate();
template.setConnectionFactory(factory);
template.setKeySerializer(new StringRedisSerializer());
template.setValueSerializer(new StringRedisSerializer());
template.setHashKeySerializer(new StringRedisSerializer());
template.setHashValueSerializer(new StringRedisSerializer());
template.afterPropertiesSet(); // 关键！漏掉这行等于没配
return template;
}</string></string>
- 用
RedisTemplate<string string></string>而非<string object></string>，从泛型层面约束值只能是字符串，避免误塞对象 -
setHashKeySerializer和setHashValueSerializer是给opsForHash()用的，如果项目里用了 Hash 结构（比如用户属性缓存），不配照样乱码 - 不要只配 key 或只配 value —— 两者都得设，否则未配置项 fallback 到默认 JDK 序列化
存中文或特殊字符时乱码怎么办？
StringRedisSerializer 默认用 UTF-8，但如果你看到 Redis CLI 里显示 "\xe4\xbd\xa0\xe5\xa5\xbd" 而不是 "你好"，问题不在序列化器，而在 Redis 客户端显示逻辑。确认方式：
- 用
redis-cli执行get your_key，如果返回带\x的转义串，说明客户端没启用 raw 模式；加--raw参数重连：redis-cli --raw -h 192.168.150.101 - Spring Boot 日志打印出的值是
???，检查 JVM 启动参数是否含-Dfile.encoding=UTF-8 - 如果用
RedisTemplate<string string></string>存了"测试"，再用redisTemplate.opsForValue().get("key")取出来是null，大概率是 key 的序列化没配，导致写入和读取用的 key 编码不一致
最易忽略的一点：Lettuce 连接池配置里的 max-wait 单位是毫秒，但 Spring Boot 2.3+ 默认单位是 Duration，写成 100 实际是 100 纳秒——连接池会瞬间超时，导致序列化配置根本没机会生效。务必核对 application.yml 里 lettuce.pool.max-wait 的值是否合理（比如 1000ms 写成 1000 而不是 1s）。
