hmset 自 redis 6.2 起被弃用，应统一使用 hset：支持批量写入、返回实际修改数、空值字段会被删除；需注意原子性（单次多字段更新）、客户端传参规范（推荐 mapping=）及代理字段数限制。
HMSET 在 Redis 6.2+ 已被标记为弃用，别再新项目里硬写
Redis 官方从 6.2 开始把 HMSET 标记为 deprecated，不是 bug，是故意的——它和 HSET 功能完全重复，且后者语义更清晰、参数更统一。现在用 HMSET 不会报错，但客户端日志可能警告，某些新版本哨兵或代理（如 RedisJSON 网关）甚至会拦截。
真正该用的是 HSET，它从 Redis 2.0 就存在，支持批量写入，语法还更直白：
HSET user:1001 name "张三" email "zhang@x.com" age 28
-
HSET返回实际新增/修改的字段数，HMSET固定返回OK，不利于调试 - 老项目若依赖
HMSET命令字面量（比如某些 ORM 的硬编码），升级前得 grep 检查所有HMSET调用点 - Redis CLI 里敲
HMSET仍能运行，但 Python 的redis-py4.0+ 默认已不推荐在文档中展示该方法
批量更新 Hash 字段时，空值字段会直接删掉，不是设为空字符串
这是最容易踩的坑：如果你传了 avatar_url ""，HSET 会真的把这个字段删掉（DEL 效果），而不是存一个空字符串。因为 Redis Hash 的字段值不能为 null，空字符串是合法值，但你代码里如果漏判、前端传了空串、或者默认值没兜住，就会意外丢失字段。
- 后端接收参数后，显式过滤掉值为
None或空字符串的键，只传有效字段给HSET - 想“清空”某个字段又保留它，得用
HSET user:1001 avatar_url "null"这类占位符，再在业务层解释 - 用
HGETALL查看结果时，注意返回结果里压根不会出现被删掉的字段，不是值为nil
大用户量下并发 HSET 多字段，字段级覆盖不保证原子性
HSET 对整个 key 是原子的，但如果你分多次调用（比如先改 name，再改 email），中间就可能被其他客户端读到半更新状态。而单次 HSET 批量写入多个字段，才是真正的原子操作——要么全生效，要么全不生效（网络断开等异常除外）。
- 必须把要更新的字段一次性收集好，拼成一个
HSET命令发出，别拆成多个HSET或混用HSET+HINCRBY - 字段数超过 500 时，部分 Redis 代理（如 Twemproxy）可能截断请求，建议单次不超过 100 字段，超了就分批加锁处理
- 如果字段之间有强依赖（比如 status 和 updated_at 必须同批次更新），更不能拆开；否则可能出现 status=active 但 updated_at 还是昨天的时间戳
Python redis-py 中传参方式不对，会导致字段名被当成值
常见错误是把字段列表直接塞进 hset() 调用，结果 key 名成了第一个字段值。比如：
conn.hset("user:1001", ["name", "张三", "email", "zhang@x.com"]) # ❌ 错！
正确写法只有两种：
conn.hset("user:1001", mapping={"name": "张三", "email": "zhang@x.com"}) # ✅ 推荐
conn.hset("user:1001", "name", "张三", "email", "zhang@x.com") # ✅ 兼容老版本
- 用
mapping=参数最安全，类型明确，IDE 也能提示 - 位置参数形式（
key, field1, value1, field2, value2...）在 redis-py 4.0+ 已标记为 legacy，未来可能移除 - 千万别用
*list解包字段数组，容易错位，尤其字段名里带冒号或空格时更危险
Redis 的 Hash 批量更新看着简单，但字段删空逻辑、并发原子性边界、客户端传参陷阱这三点，线上出过太多静默故障。别信“反正命令能跑通”，得盯着实际数据存进去的样子。
