必须传指针给reflect.ValueOf并调用.Elem()才能修改切片或map；需检查.CanAddr()和.CanSet()；追加切片或写入map后须显式.Set()写回原值；键类型须严格匹配；避免热路径重复调用reflect.TypeOf/ValueOf。
怎么用 reflect.ValueOf 安全拿到切片或 map 的可修改值
直接对参数调 reflect.ValueOf 得到的是只读副本，改了也没用。必须传指针进去，再用 .Elem() 解引用——否则所有增删改操作都会 panic 或静默失败。
- 切片要传
&slice，不是slice；map 同理，必须是&m，因为 map 本身是引用类型但反射需要地址才能修改底层结构 - 检查
.CanAddr()和.CanSet()是必要步骤，尤其在函数参数里传入非指针时，跳过这步大概率遇到reflect: reflect.Value.SetMapIndex using unaddressable map - 注意：
reflect.MakeMap创建的是新 map，不能直接替代原变量；想“替换”得用.Set()把新值写回原reflect.Value
reflect.Append 和 reflect.MapIndex 的典型误用场景
很多人以为 reflect.Append 能直接往原切片追加，其实它返回新 reflect.Value，不自动写回；同理，reflect.MapIndex 只读取，赋值得用 .SetMapIndex() 配合 reflect.Value 键值对。
- 切片追加后必须显式
oldSlice.Set(newSlice)，否则原变量不变；漏掉这句就白操作了 - map 写入前，键的
reflect.Value必须和 map 声明的 key 类型严格一致（比如 map[string]int 里不能用reflect.ValueOf("k").Convert(reflect.TypeOf(int(0)))强转），否则报panic: reflect: call of reflect.Value.MapIndex on interface Value - 删除 map 元素不是设为 nil，而是调
.SetMapIndex(key, reflect.Value{})，第二个参数传零值reflect.Value{}
性能陷阱：为什么别在热路径反复用 reflect.TypeOf 和 reflect.ValueOf
每次调用 reflect.TypeOf 或 reflect.ValueOf 都触发运行时类型查找，开销远高于普通接口断言。高频操作（如 JSON 序列化中间层、ORM 字段映射）里反复调用，CPU 火焰图上会明显凸起。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 把
reflect.Type和常用reflect.Value模板缓存起来，比如用sync.Map存map[reflect.Type]fieldInfo - 避免在 for 循环里对同一变量重复调
reflect.ValueOf(x)；提前提取一次，复用其.Field()、.Index()等方法 - 如果只是判断类型是否为 slice/map，用
v.Kind() == reflect.Slice比v.Type().Kind() == reflect.Slice少一次指针解引用
嵌套结构体字段修改时，reflect.Value.FieldByName 的边界条件
字段名大小写敏感，且仅能访问导出字段（首字母大写）。非导出字段即使用 .FieldByName 也返回无效 reflect.Value，后续 .Set() 直接 panic。
立即学习“go语言免费学习笔记（深入）”；
- 想改非导出字段？不行——Go 反射不突破语言可见性规则，这是设计使然，不是技巧问题
- 嵌套 map 或 slice 字段，比如
user.Profile.Addresses，得链式调用：v.FieldByName("Profile").FieldByName("Addresses")，中间任一环节为零值（nil struct / nil slice）都会 panic - 安全做法是每步后加
if !v.IsValid() || !v.CanInterface() { ... }，而不是靠 defer recover 捕获
最常被忽略的是：反射修改 map 或 slice 后，如果原变量是局部变量且没被其他地方引用，GC 可能提前回收底层数组，导致后续访问出现意外的零值或 panic——务必确认生命周期和持有者关系。
