HMGET不能直接返回结构体字段映射，因其返回按字段顺序排列的[]interface{}值列表（如["Alice","30",nil]），而非键值对或JSON对象，需手动类型断言、nil判断及逐字段赋值；结构体字段标签不生效，必须显式传入fields参数并严格匹配顺序。
为什么 HMGET 不能直接返回结构体字段映射？
Go 的 redis.Client.HMGet 返回的是 []interface{}，每个值都是 interface{} 类型（可能是 string、nil 或其他），不会自动按字段名绑定到结构体。你不能指望它像 ORM 那样“自动映射”，必须手动做类型断言和赋值。
常见错误是直接用 json.Unmarshal 尝试解析整个哈希结果——但 HMGET 返回的是按字段顺序排列的值列表，不是键值对，更不是 JSON 对象。
-
HMGET user:123 name age email返回["Alice", "30", "alice@example.com"]，顺序严格对应命令中字段顺序 - 如果某个字段不存在，对应位置是
nil，不是空字符串或零值 - 字段名大小写、拼写必须和 Redis 中完全一致，Go 结构体字段标签（如
redis:"name"）在此场景下不生效
如何安全地批量读取并映射到结构体？
核心思路：先用 HMGET 拿到值切片，再按字段顺序逐个解包、类型转换、赋值。关键是要处理 nil 和类型不匹配。
示例函数签名建议：func HMGetToStruct(ctx context.Context, client *redis.Client, key string, dest interface{}, fields ...string) error
- 使用
reflect获取结构体地址和可导出字段（需确保dest是指针） - 调用
client.HMGet(ctx, key, fields...)，检查返回错误和长度是否匹配fields - 遍历
fields和返回值，对每个val做if val == nil { continue }判断，再尝试val.(string)断言 - 对数字字段（如
int、int64）额外调用strconv.ParseInt，避免 panic - 跳过不可导出字段（首字母小写），否则
reflect.Set会静默失败
字段顺序错位或缺失字段导致映射失败怎么办？
这是最常踩的坑：传给 HMGET 的 fields 顺序和结构体字段声明顺序不一致，或者 Redis 中缺少某个字段，就会把值塞到错误字段上。
正确做法是**显式声明字段顺序**，而不是依赖结构体反射顺序：
- 不要用
reflect.ValueOf(dest).Elem().NumField()自动提取所有字段名——这无法保证与 Redis 存储顺序一致 - 始终显式传入
fields参数，例如HMGetToStruct(ctx, c, "user:123", &u, "name", "age", "email") - 若字段可能为空，结构体对应字段应为指针（如
*string）或带omitempty的可空类型，并在赋值前判断val != nil - 调试时可先打印
vals, err := client.HMGet(ctx, key, fields...).Result()看原始返回，确认顺序和nil位置
性能与并发注意事项
单次 HMGET 是原子的，但映射过程本身不涉及网络，瓶颈在 Redis 往返。不过有几点容易忽略：
- 不要在循环里反复调用该函数查多个 key——改用
pipeline或MGET+ 多个HMGET批量发包（但注意 Redis pipeline 不支持跨 key 的事务语义） - 如果字段很多（>50），考虑是否真的需要全量读取；部分场景用
HGETALL更省事，但返回无序，仍需自己按需提取 -
reflect在首次调用时有轻微开销，可缓存reflect.Type和字段索引映射（尤其高频调用时），但多数业务场景没必要过早优化 - 注意上下文超时：
HMGET调用必须传带 timeout 的ctx，否则阻塞可能拖垮整个 goroutine
真正麻烦的不是写这个函数，而是后续字段增减时同步维护 fields 列表和结构体定义——漏掉一个，运行时才报错，且很难定位。
