反射遍历 map 时 panic 是因传入 nil 或未初始化 map，需用 IsValid() 和 Kind() == reflect.Map 双重校验；MapRange 高效但限编译期已知类型，反射支持运行时任意 map 类型但慢 10–100 倍；修改仅允许更新已有 key 的 value，不可新增键或扩容。
Go 反射遍历 map 时 panic: reflect: call of reflect.Value.MapKeys on zero Value
这是最常遇到的错误，说明你传给 reflect.ValueOf 的是个 nil map 或未初始化的 map 变量。反射无法对空值做 MapKeys 操作。
实操建议：
- 先用
reflect.Value.IsValid()和reflect.Value.Kind() == reflect.Map双重校验 - 避免直接对函数返回的 map 做反射（比如
getMap() != nil仍可能返回零值 map） - 若 map 是结构体字段，需确保结构体本身非 nil，且该字段已赋值
示例：
if v := reflect.ValueOf(m); v.IsValid() && v.Kind() == reflect.Map {
for _, key := range v.MapKeys() {
val := v.MapIndex(key)
fmt.Printf("%v: %v\n", key.Interface(), val.Interface())
}
}
为什么不用 mapiter（Go 1.21+ 的 MapRange）而选反射
MapRange 是语言原生支持、零开销的迭代方式，但只适用于编译期已知类型的 map；反射是唯一能在运行时处理任意 map[K]V 类型（K/V 都未知）的手段。
关键区别：
立即学习“go语言免费学习笔记（深入）”；
-
MapRange要求 map 类型在代码中可见，比如map[string]int，不能用于interface{}中藏的 map - 反射可穿透
interface{}、结构体嵌套字段、JSON 解析后的map[string]interface{} - 性能上，反射慢 10–100 倍，但换来了类型无关性 —— 这是通用序列化/调试工具的刚需
反射遍历 map 时 key 和 value 的类型怎么安全取出来
直接调 Interface() 很危险：如果 key 是自定义类型或含未导出字段，会 panic；value 是指针或 chan 时也容易出错。
稳妥做法是分层判断：
- 用
key.Kind()和val.Kind()先分类（reflect.String、reflect.Int、reflect.Struct等） - 基础类型（string/int/bool/float）可放心用
Interface() - 对
reflect.Struct或reflect.Ptr，优先用String()或Kind().String()作字符串表示，避免深拷贝 - 遇到
reflect.Invalid（比如 map 中存了 nil interface{}），跳过或打日志
示例片段：
if key.Kind() == reflect.String {
k = key.String()
} else {
k = fmt.Sprintf("%v", key.Interface()) // 仅当确定安全时才用 Interface()
}
遍历过程中修改 map 导致 panic: assignment to entry in nil map
反射对象本身不持有 map 数据，只是“视图”。通过 v.MapIndex(key).Set(x) 修改值是允许的，但 v.SetMapIndex(key, val) 添加新键会失败 —— 因为反射无法扩容底层哈希表。
真正能安全修改的只有：
- 已存在的 key 对应的 value（用
MapIndex(key).Set(...)） - 必须新增键值对时，得先用原生 map 操作构造新 map，再用
reflect.Value.Set()替换整个值 - 千万别在遍历中用
delete()或m[key] = nil，反射层看不到这些变更，后续MapIndex可能返回无效值
反射遍历 map 的核心约束就一条：它只读、不扩容、不接管内存。一旦涉及动态增删或不确定类型深度，就得提前规划好边界检查和降级策略 —— 比如 fallback 到 json.Marshal 再解析，有时比硬扛反射更稳。
