reflect.TypeOf 返回的是接口包装后的类型，原始类型信息被擦除；reflect.ValueOf 默认返回不可寻址副本，需传指针或用 .Addr() 才能修改；.Interface() 不总是安全，应优先用 .Int() 等具体方法。
为什么 reflect.TypeOf 返回的不是你想要的类型？
因为 reflect.TypeOf 对传入值做了一次“接口包装”，原始类型信息被擦除一层。比如传入 *int，它返回的是 *int 的反射表示；但如果你传的是 int 变量本身，它不会告诉你这个 int 是局部变量还是字段——只告诉你底层是 int。
- 常见错误：用
reflect.TypeOf(x).Name()判断自定义结构体名，结果对指针或接口类型返回空字符串（Name()只对命名类型在包顶层有效） - 正确做法：优先用
reflect.TypeOf(x).Kind()判断基础分类（struct、ptr、slice等），再用reflect.TypeOf(x).String()看完整描述 - 注意：如果 x 是
nil接口，reflect.TypeOf(x)返回nil，直接调用会 panic
reflect.ValueOf 为啥一取字段就 panic：「invalid memory address」？
因为 reflect.ValueOf 默认返回不可寻址的副本。想读写结构体字段、调用方法，必须确保底层值可寻址——也就是传入指针，或用 .Addr() 获取地址（前提是原值本身可寻址）。
- 典型场景：遍历结构体字段并修改，必须从
&myStruct开始，不能从myStruct开始 - 参数差异：
reflect.ValueOf(&x).Elem()得到可修改的x；而reflect.ValueOf(x)即使x是指针，得到的也是该指针值的副本，不能.Elem() - 容易踩的坑：对常量、字面量、函数返回值直接调用
.Field()，比如reflect.ValueOf(struct{A int}{1}).Field(0).Int()看似能读，但一旦换成.SetInt()就 panic
怎么安全地从 reflect.Value 取出原始 Go 值？
不能无脑调 .Interface()。它只在值可寻址、且未被修改过类型信息时才安全返回原始类型。否则可能 panic 或返回 interface{} 导致类型丢失。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 使用前先检查：
v.CanInterface()—— 不是所有reflect.Value都能转回 interface - 更稳妥的做法：按需用具体取值方法，比如
v.Int()、v.String()、v.Bool()，它们不依赖接口转换，且自带类型校验 - 性能提示：
.Interface()触发一次内存分配和类型断言，高频场景下比直接调.Int()慢 2–3 倍 - 兼容性注意：如果
v是未导出字段（小写开头），.Interface()会 panic，哪怕你只是想读
反射访问嵌套结构体字段时，CanSet() 总是 false 怎么办？
因为 Go 的反射要求“可设置性”必须沿整个路径传递：最外层值必须可寻址，中间每个指针解引用也必须落在可寻址内存上。只要某一级是值拷贝（比如 struct 字段是值类型且非指针），后续字段就不可设。
立即学习“go语言免费学习笔记（深入）”；
- 示例：
type A struct{ B B }; type B struct{ X int }，对A{B: B{X: 1}}的B.X调.CanSet()一定为 false - 解决办法：要么一开始就传
&A{...}，要么确保嵌套字段本身是指针类型（B *B） - 调试技巧：逐级打印
v.CanAddr()和v.Kind() == reflect.Ptr，定位哪一级断了可寻址链 - 容易被忽略的点：即使你用
reflect.ValueOf(&a).Elem()进入了 a，如果 a.B 是值类型，.FieldByName("B").FieldByName("X")的最后一级仍然不可设
