RedisTemplate 不支持对不同 Key 字符串使用不同序列化器，其 keySerializer 是全局单例配置；需通过多实例隔离（如 stringKeyRedisTemplate 和 typedKeyRedisTemplate）实现语义区分，并显式配置 hash/zset 子结构序列化器。
RedisTemplate 的 keySerializer 是全局的，不能按 Key 动态切换
直接回答核心问题：RedisTemplate 不支持“对不同 Key 字符串使用不同序列化器”。它的 setKeySerializer() 是单例级配置，一旦设定，所有 Key（无论内容是 "user:1" 还是 "cache:token"）都走同一套序列化逻辑。试图在运行时根据 Key 名称分支选择序列化器，会破坏 RedisTemplate 的线程安全设计，也违背 Spring Data Redis 的抽象契约。
为什么不能用 GenericJackson2JsonRedisSerializer 做 Key 序列化
常见错误是把 GenericJackson2JsonRedisSerializer 同时用于 Key 和 Value：
- 它会给字符串 Key 包一层 JSON 封装，比如
"user:1"变成{"@class":"java.lang.String","value":"user:1"} - Redis 命令行（
redis-cli）或图形化工具里看到的就是乱码，如"\xac\xed\x00\x05t\x00\tuser:1"或 JSON 字符串本身 - 其他语言客户端（如 Python 的 redis-py）根本无法识别这种格式，跨语言场景直接失效
- Hash 结构的
hset字段名、Sorted Set 的 member 也会被同样污染
真正可行的分 Key 类型处理方案
若业务上确实需要区分语义（例如：业务 Key 要可读，内部元数据 Key 要带类型信息），应通过**多实例隔离 + 显式命名**实现，而非单个 RedisTemplate 内部动态切换：
- 定义多个
@Bean：一个专用于纯字符串 Key 场景（如缓存、计数），用StringRedisSerializer；另一个用于需反序列化复杂对象 Key 的极少数场景（如自定义路由表），用GenericJackson2JsonRedisSerializer - Bean 名称体现用途，例如
stringKeyRedisTemplate和typedKeyRedisTemplate，调用方显式注入对应实例 - 避免复用同一个
RedisTemplate实例去混存两类 Key —— 这会导致反序列化失败或类型误判 - 如果必须共用连接池，可通过
RedisConnectionFactory共享，但序列化器必须拆开配置
最容易被忽略的 Hash 和 ZSet 场景
很多人只改了 keySerializer 和 valueSerializer，却漏掉 Hash 和 Sorted Set 的子结构序列化器：
-
setHashKeySerializer()控制HSET user:1 name "Alice"中的name字段名（不是user:1） -
setHashValueSerializer()控制name对应的值"Alice" -
setZSetSerializer()影响ZADD leaderboard 100 "uid:123"中的"uid:123"（member）和 score 的序列化方式 - 这些不设，默认继承
keySerializer/valueSerializer，极易引发字段名乱码或 member 解析失败
真正要“按 Key 类型区分”，得靠实例拆分 + 显式调用，而不是幻想一个 Bean 能智能路由。否则，你写的 Key 在 redis-cli keys * 里根本看不到原样，排查成本远高于多配两个 Bean。
