Hash比String更适合存用户会话，因为支持单字段原子更新无需反序列化整个对象，避免IO和CPU浪费，实测延迟从2–5ms降至0.3–0.8ms，且适用于字段多、读写不均的场景如用户会话、商品详情。
Hash比String更适合存用户会话，因为单字段更新不用反序列化整个对象
用 String 存会话时，每次改 lastLoginIp 或自增 loginCount，都得先 get 整个 JSON，反序列化成 Java 对象，改完再序列化 set 回去——IO 和 CPU 双浪费。而 Hash 直接操作字段：hincrby 改计数、hset 更新 IP，底层不碰其他字段。
常见错误现象：线上接口响应变慢，监控发现 Redis 的 GET/SET QPS 翻倍，但业务逻辑其实只改了一个字段——大概率是误用了 String 存结构化数据。
- 适用场景：用户会话、商品详情、配置中心参数（字段多、读写频次不均）
- 性能影响：单字段写入延迟从 2–5ms 降到 0.3–0.8ms（实测 Lettuce + 默认连接池）
- 注意点：Java 21 的
LocalDateTime默认无法被GenericJackson2JsonRedisSerializer序列化，存Hash字段前得统一转成String或用自定义RedisSerializer
RedisTemplate.opsForHash() 是最常用也最容易踩坑的 API
opsForHash() 提供了标准的 Hash 操作，但它的泛型和序列化行为容易引发乱码或 ClassCastException。比如用 redisTemplate.opsForHash().put("user:1001", "username", "zhangsan") 看似没问题，但如果 value 是对象，而 template 的 value serializer 是 JdkSerializationRedisSerializer，就会存一堆不可读字节。
正确做法是明确指定序列化器，或改用 BoundHashOperations 封装键作用域：
- 推荐初始化方式：
BoundHashOperations<string string object> ops = redisTemplate.boundHashOps("user:1001");</string> -
ops.put("email", "zhangsan@example.com")—— key 和 field 都用String，value 用Object，配合 JSON 序列化器更安全 - 避免直接调用
opsForHash().put(key, field, value)传复杂对象，除非你确认 template 的 value serializer 已设为GenericJackson2JsonRedisSerializer - 过期时间必须单独设：
ops.expire(30, TimeUnit.MINUTES)，Hash 本身不支持 TTL，TTL 是作用于外层 key 的
Hash 不是万能的：小对象才省内存，大对象反而增加碎片
Redis 对小 Hash（field 数 ≤ 512，单 value ≤ 64 字节）会启用 ziplist 编码，内存占用比拆成多个 String 键低 30%~50%。但一旦超过阈值，自动转为 hashtable 编码，内存开销和多个 String 差不多，还多了哈希表管理成本。
所以别盲目把所有对象都塞进 Hash。判断依据很实际：
- 字段数少（≤ 20）、单值短（如用户名、状态码、时间戳字符串）→ 适合 Hash
- 含长文本（如用户签名、商品描述）、二进制内容（头像 Base64）、嵌套 JSON → 改用
String或拆成独立 key - 需要对某个字段做
INCR/DECR→ 必须用 Hash，String 不支持原子数值运算 - 要批量查多个字段（
hmget）且字段名固定 → Hash 减少网络往返，比多次get更高效
Spring Data Redis Repository 对 Hash 是“高级封装”，但不适合高频写场景
用 @RedisHash("user") + CrudRepository 确实写起来像 JPA，但每次 save() 都会全量覆盖 Hash，相当于执行 hset user:1001 field1 val1 field2 val2 ...。如果对象有 15 个字段，每次只改 1 个，却发 15 个 field-value 对过去，带宽和 CPU 都浪费。
它真正适合的场景是：
- 配置类数据（字段稳定、读多写少、变更频率低）
- POJO 结构简单、字段数 ≤ 5、无频繁部分更新需求
- 团队强依赖 JPA 风格开发，愿意为可读性牺牲一点性能
- 不要用它做登录态刷新、库存扣减、实时统计这类高频单字段操作
真实业务里，BoundHashOperations 手动控制字段粒度，才是平衡可维护性与性能的主流选择。那些没想清楚字段访问模式就套 Repository 的项目，上线后往往要重构。
