RedisTemplate默认使用JdkSerializationRedisSerializer，导致字符串存入时添加\xac\xed\x00\x05等二进制头部而显示乱码，并非截断；真截断多源于自定义序列化器中Arrays.copyOf(..., N)的静默限制。
RedisTemplate 默认序列化器不支持大 String
Spring Boot 2+ 默认使用 JdkSerializationRedisSerializer（除非显式配置），它会对所有值做 Java 原生序列化，导致存入的 String 前后被加上 4–8 字节头部（如 \xAC\xED\x00\x05），再经 Base64 或直接二进制存储。这不是“截断”，而是**乱码显示 + 实际长度膨胀**，容易被误判为内容丢失。
更隐蔽的问题是：某些自定义序列化器（比如早期项目里手写的 CustomStringRedisSerializer）会主动限制字节数，例如强制 Arrays.copyOf(..., 1024) —— 这才是真截断，且不会报错，静默丢数据。
- 用 Redis CLI 查看 key：执行
get your_key，如果返回乱码或明显比原始字符串短，优先怀疑序列化器 - 检查代码中是否手动注册了
RedisSerializer实现类，尤其注意serialize()方法里是否有if (bytes.length > N) return Arrays.copyOf(..., N)类逻辑 - 默认
StringRedisSerializer是安全的，它只做 UTF-8 编解码，无长度限制
正确配置 StringRedisSerializer 避免隐式截断
必须确保 RedisTemplate<String, String> 的 value 序列化器是 StringRedisSerializer，而不是泛型版 RedisTemplate<String, Object> 配的 GenericJackson2JsonRedisSerializer（后者对纯字符串也加 JSON 包装，体积增大且可能触发底层缓冲区限制）。
推荐配置方式：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
@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()); // 关键：不是 GenericJackson2JsonRedisSerializer
template.setHashKeySerializer(new StringRedisSerializer());
template.setHashValueSerializer(new StringRedisSerializer());
template.afterPropertiesSet();
return template;
}
- 不要复用
RedisTemplate<String, Object>存纯字符串，类型擦除 + 序列化器不匹配极易出问题 - 如果必须用
Object泛型（比如存多种类型），value 序列化器应选GenericJackson2JsonRedisSerializer，但需确认 JSON 序列化后总长度未超 Redis 单 value 限制（官方建议 ≤16KB） - Spring Boot 2.6+ 默认客户端是 Lettuce，其 socket 缓冲区默认 16MB，一般够用；若仍截断，需查
lettuce.pool.max-active是否过小导致连接复用异常
验证字节长度是否真超限
Redis 协议本身不限制 value 大小，但实际受内存、网络帧、客户端实现影响。真正需要检查的是：序列化后字节数是否超过你环境中的隐式阈值（如某些代理、监控工具、旧版 Jedis 客户端有 1MB 硬限制）。
快速验证方法：
String raw = "a".repeat(2000); // 构造 2000 字符字符串
byte[] encoded = raw.getBytes(StandardCharsets.UTF_8);
System.out.println("UTF-8 bytes: " + encoded.length); // 输出 2000
// 再用你当前 RedisTemplate 的 valueSerializer 测试：
byte[] serialized = template.getValueSerializer().serialize(raw);
System.out.println("Serialized bytes: " + serialized.length); // 若远大于 2000，说明用了 Jackson 或 JDK 序列化
- 如果
serialized.length > raw.length * 2，基本可判定用了 JSON/JDK 序列化，不是截断而是膨胀 - 若
serialized.length == raw.length但 Redis 中取出来变短，检查是否 Redis 服务端启用了maxmemory-policy导致 LRU 淘汰了大 key（但淘汰是删整个 key，不是截断） - 生产环境建议加日志：在 set 操作前后打印
value.length()和serializer.serialize(value).length，定位发生在哪一层
大 String 场景下更稳妥的替代方案
当单个 value 稳定超过 10KB，不建议强依赖 SET 指令。Redis 对大 value 的读写会阻塞主线程、放大网络延迟、增加 RDB/AOF 文件体积。
- 拆分为多个 key：用
key:part:001,key:part:002+HSET或LPUSH组合，应用层拼接 - 改用外部存储：把大文本存到对象存储（如 S3/OSS），Redis 只存 URL 和元信息
- 启用压缩：在序列化前用
DeflaterOutputStream压缩，反序列化时解压（注意 CPU 开销和兼容性） - 避免用
StringRedisTemplate的opsForValue().set(key, value, timeout)直接传巨量字符串，改用execute()原生命令并控制分片
最常被忽略的一点：问题往往不出在 Redis 或 Spring Boot，而出在开发人员自己写的序列化器里那行 Arrays.copyOf(..., 1024) —— 它安静运行了两年，直到某天运营导入一个长文案才暴露。查代码比调配置更快。
