Go反射调用方法前必须确认接收者类型匹配：指针接收者需传&obj，值接收者可用obj或&obj.Elem；参数须严格匹配数量与类型，返回值需解包校验。
反射调用方法前必须确认接收者类型是否匹配
Go 反射调用方法不是“只要名字对就能跑”，最常 panic 的原因就是接收者类型错配。比如你有一个 (*User).Save 方法（指针接收者），却传了 reflect.ValueOf(user)（值），那 MethodByName("Save") 返回的 reflect.Value 是零值，.IsValid() 为 false，直接 .Call() 就 panic。
- 指针接收者方法 → 必须用
reflect.ValueOf(&obj) - 值接收者方法 → 可用
reflect.ValueOf(obj)或reflect.ValueOf(&obj).Elem() - 不确定接收者类型？统一用
&obj最安全，尤其涉及字段修改时 - 检查手段：调用前加
if !method.IsValid() || !method.CanCall()
参数必须包装成 []reflect.Value，且类型数量严格一致
reflect.Value.Call() 不接受原始参数，也不做隐式转换。传 int64 给期望 int 的参数、或少传一个 error 占位符，都会 runtime panic —— 而且错误信息不提示具体哪错了，只报 reflect: Call using zero Value 或 reflect: Call of non-function 这类模糊信息。
- 每个参数必须显式转成
reflect.Value：用reflect.ValueOf(arg) - 提前校验：用
method.Type().NumIn()对比len(args) - 基础类型别名不兼容：如
type Code int和int视为不同类型 - 空参调用写
nil或[]reflect.Value{}都可以，但推荐后者更明确
返回值是 []reflect.Value，不能直接用，要手动解包
无论方法返回 string、(int, error) 还是无返回值，.Call() 总是返回一个切片。你不能假设第一个元素一定存在，也不能用 .Interface() 直接断言到业务类型而不检查有效性。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先判断
len(results) > 0，再取results[0] - 基本类型优先用原生方法：
results[0].String()、results[0].Int()、results[0].Bool()，比.Interface().(string)更安全（避免 panic） - 有
error返回时，最后一个元素通常对应它，用results[len(results)-1].Interface()再断言 - 如果方法没返回值，
results是空切片，访问results[0]会 panic
修改结构体字段必须传指针，且字段名必须导出
想用反射改 User.Name？没问题。想改 User.name（小写）？不行 —— 反射压根看不到它，FieldByName("name") 返回零值，.CanSet() 为 false，调 .SetString() 会 panic。
立即学习“go语言免费学习笔记（深入）”；
- 必须传结构体指针：
reflect.ValueOf(&user).Elem()才能获得可设置的值 - 字段名首字母必须大写（即导出），否则反射不可读写
- 修改前务必检查：
field := v.FieldByName("Name"); if field.CanSet() { field.SetString("New") } - 嵌套结构体要逐层
Elem()解指针，常见漏掉一层导致CanSet()==false
反射不是语法糖，它是绕过编译期检查的运行时操作。每一次 MethodByName、FieldByName、Call，背后都是类型校验和地址合法性检查。省掉任何一个 IsValid() 或 CanSet() 判断，都可能在某个边缘 case 下突然崩掉 —— 而那个 case 往往出现在上线后。
