Redis Hash增量修改不能直接用putAll，因其会将整个Map序列化为新值覆盖而非字段级合并；安全做法是用HSET或hashOperations.put单字段写入，确保字段级增量更新。
Redis Hash 增量修改为什么不能直接用 putAll？
Java 客户端（比如 Lettuce 或 Jedis）的 HashOperations.putAll 方法看似能“批量写入”，但实际是把整个 Map 序列化成一个完整 value，再用 HSET key field1 val1 field2 val2 ... 发给 Redis —— 这本身确实是增量字段写入，**但前提是你的序列化方式不破坏原有字段结构**。问题出在：如果 value 是 JSON 或自定义对象，putAll 会把整个 Map 当作新值覆盖，而不是按 field 粒度合并。
真正安全的增量修改：用 HSET 单字段或批量字段写入
Redis 的 HSET 天然支持字段级增/改，不存在“全量序列化”风险，只要确保你传的是原始字段名和原始值（非嵌套对象），就一定是增量。
- 用
hashOperations.put(K key, HK hashKey, HV value)写单个字段，最稳妥 - 用
hashOperations.putAll(K key, Map extends HK, ? extends HV> m)也可以，但必须满足：m中每个value是可直接序列化的基础类型（String/Integer/Long 等），且反序列化逻辑与之前一致 - 避免把一个嵌套对象（如
User）整个塞进某个 field；若真要存对象，应拆成多个 field，比如user:name、user:age
踩坑典型场景：JSON 字符串作为 Hash value
常见错误是把整个对象转成 JSON 存进一个 field，比如 HSET user:1001 data "{\"name\":\"Alice\",\"score\":85}"。这时你想“只改 score”，却只能取出来、反序列化、改字段、再序列化、再 HSET —— 这就触发了全量读写+序列化，完全失去 Hash 的字段优势。
- 正确做法：每个业务字段单独设 field，
HSET user:1001 name "Alice" score 85 level "S" - 这样改分值只需
HSET user:1001 score 92，网络开销小，无反序列化压力 - 如果已有 JSON 存储格式无法重构，就别用 Hash，改用 String + Lua 脚本做原子 JSON patch（但复杂度陡增）
性能与兼容性提醒：Lettuce vs Jedis 的 putAll 行为差异
两者底层都调 HSET，但序列化策略不同：Jedis 默认用 JDK 序列化（不推荐），Lettuce 默认用 StringCodec（更轻量）。如果你用的是自定义 GenericJackson2JsonRedisSerializer，putAll 会把整个 Map 序列化为一个 JSON 字符串存进 value，这已经不是 Hash 结构了——它只是 key 下挂了一个字符串，所有 field 都丢失。
- 检查你的
RedisTemplate配置：Hash 操作必须配StringRedisTemplate或明确指定HashKey/HashValue的序列化器为StringRedisSerializer - 用
redis-cli执行HGETALL your_key看返回是否为清晰的 field-value 对，而不是一堆乱码或单个大 JSON - 线上环境建议禁用任何基于对象整体序列化的 Hash 使用方式，从源头杜绝“伪增量”
真正靠得住的增量，永远建立在字段可独立寻址的基础上。一旦你开始琢磨“怎么让 putAll 不序列化整个对象”，说明结构设计已经偏离了 Hash 的初衷。
