HSET 是更新 Hash 单个或多个字段的唯一推荐方式，原子安全、避免覆盖；禁用 HMSET（已弃用），字段名应小写下划线分隔，批量更新须用多参数 HSET 一次提交。
用 HSET 更新单个字段最安全
直接改对象某个属性时，HSET 是唯一推荐方式。它原子性地设置一个 field-value 对，不存在覆盖风险，也不依赖客户端本地缓存状态。
常见错误是误用 SET 把整个 Hash 当字符串存，或在业务逻辑里先 HGETALL 再拼新结构重写——这会丢失并发写入的其他字段更新。
-
HSET user:1001 name "Alice"—— 安全，只动name -
HSET user:1001 age 28 last_login "2024-04-05"—— 错！这是两条命令，不是原子批量；应拆成两个独立HSET - 不要在代码里
HGETALL→ 修改 map →HMSET，除非你加了分布式锁且能容忍短暂不一致
HMSET 已弃用，一律改用 HSET 多参数形式
Redis 4.0.0 起 HMSET 被标记为 deprecated，6.2+ 官方文档已移除其独立命令页。实际行为和 HSET 完全一致，但语法冗余、易混淆。
使用 HSET 多参数（即 HSET key field value [field value ...]）替代，语义更清晰，兼容性更好。
- 旧写法（不推荐）：
HMSET user:1001 name "Bob" age 31 city "Shanghai" - 新写法（必须）：
HSET user:1001 name "Bob" age 31 city "Shanghai" - 注意：Redis CLI 和大多数客户端（如 Jedis、redis-py）已对
HMSET做了向后兼容映射，但代码里显式写HSET更利于维护和审计
字段名设计要防冲突，别用点号或嵌套路径
Hash 的 field 是纯字符串，Redis 不解析结构。如果存 profile.avatar.url 这类带点的 field，后续想按前缀批量操作（比如查所有 avatar 字段）就得用 HSCAN 配模式匹配，效率低且易漏。
更麻烦的是，不同语言客户端对“对象扁平化”策略不一，有的自动加点，有的用下划线，混用会导致同一个逻辑在不同服务里写进不同 field 名。
- 推荐：用简单、小写、下划线分隔的 field 名，如
avatar_url、is_vip - 避免：
profile.avatar、user.profile.name、data-json - 如果真需要嵌套结构，要么拆成多个 Hash（如
user:1001+user:1001:profile），要么序列化后存进 String 类型
大量字段更新时，HSET 性能足够，但要注意网络往返
单次 HSET 最多支持 1024 个 field-value 对（实际受协议包大小限制），日常对象更新完全够用。性能瓶颈通常不在 Redis 侧，而在客户端发命令的次数和网络延迟。
例如循环调用 20 次 HSET 更新 20 个字段，比一次多参数 HSET 慢 5–10 倍（取决于 RTT）。
- 批量更新务必合并：用
HSET user:1001 f1 v1 f2 v2 ... f20 v20 - 不要依赖 pipeline 包裹多个单 field
HSET——虽然能减少往返，但不如一次多参数干净 - 如果字段动态生成（比如表单提交的任意 key），需在客户端拼好参数列表再发，避免服务端拼接字符串引发注入或编码问题
字段名约定和批量写入时机，这两处最容易被跳过测试直接上线，出问题时表现为部分属性丢失或覆盖，排查起来要翻日志比对每次 HSET 的参数顺序。
