value.setmapindex要求key类型严格匹配go反射类型，不自动转换如int与int64；必须确保map value可寻址且可设置，key需显式构造匹配类型，setiterkey不可用于修改map。
Value.SetMapIndex 要求 key 类型严格匹配
Go 反射中 Value.SetMapIndex 不会自动转换 key 类型，哪怕只是 int 和 int64 的差异，也会 panic：「reflect: call of reflect.Value.SetMapIndex on map Value」。这不是 bug，是类型系统在反射层的严格执行。
常见错误现象：panic: reflect: call of reflect.Value.SetMapIndex on map Value，往往发生在用 reflect.ValueOf(42)（int）去设一个 map[int64]string 时。
- 先用
mapValue.MapKeys()拿一个已有 key，再用它的类型构造新 key，最稳妥 - 若需手动构造，必须显式转换：比如 map 声明为
map[int64]string，就用reflect.ValueOf(int64(42))，而非reflect.ValueOf(42) - 注意 struct tag 或 JSON 解析后进来的 map，key 往往是
string，但业务代码可能误以为是interface{}—— 实际传入必须是reflect.ValueOf("foo")，不是reflect.ValueOf(interface{}("foo"))
Value.SetIterKey 在遍历中修改 map 时根本不能用
Value.SetIterKey 是只读操作的残留接口，它不写入 map，也不改变迭代状态，调用它没有任何副作用。官方文档没明说，但源码里它直接 panic：「reflect: Value.SetIterKey called on invalid value」。
使用场景其实只有一个：你误把 SetMapIndex 记成 SetIterKey，然后卡在调试里半天。
立即学习“go语言免费学习笔记（深入）”；
- 别试图用
SetIterKey更新 map 元素 —— 它不存在这个能力 - 遍历 map 并更新值，正确做法是：用
iter.Next()拿到key和value，再对原 map 的Value调用SetMapIndex(key, newValue) - 如果 map 是指针类型（
*map[string]int），记得先Elem()再操作，否则SetMapIndex会报「can't SetMapIndex on unaddressable value」
set 操作前必须检查 addressable 和 canSet
反射写入失败，90% 出在没过这两关。Value.SetMapIndex 要求目标 map value 是 addressable（可寻址）且 canSet（可设置），否则 panic。
典型错误：对函数参数传入的 map 直接反射赋值，或对 struct 字段未导出却尝试修改其 map 字段。
- 用
value.CanAddr() && value.CanSet()显式判断，比靠 panic 更早发现问题 - 从 struct 字段取 map 时，确保字段是 exported（首字母大写），否则
Field(i)返回的 value 不可 set - 从 interface{} 解包时，
reflect.ValueOf(v).Elem()前务必确认 v 是指针，否则Elem()会 panic - map 本身是引用类型，但反射 value 若来自常量、字面量或非指针参数，仍是不可寻址的
性能敏感场景下，反射写 map 是明显瓶颈
每次 SetMapIndex 都触发类型检查、键哈希、内存分配（如 key/value 需反射包装），比原生 map 赋值慢 10–50 倍。线上高频路径里混用反射写 map，很容易成为 CPU 热点。
兼容性倒没什么坑 —— Go 1.0 以来行为稳定，但代价是没法优化。
- 批量写入优先用原生循环 + 类型断言，仅当 key/value 类型不确定时才兜底用反射
- 避免在 for-range 中反复调用
reflect.ValueOf；把Value缓存起来复用 - 如果 map key 是固定几种类型（如 string/int），可提前建好 switch 分支，绕过通用反射逻辑
真正麻烦的从来不是怎么调用那两个方法，而是搞清当前 value 是不是 addressable、key 类型到底从哪来、以及——你是不是真的需要在运行时改 map，而不是换个设计让类型在编译期就确定。
