reflect需通过场景驱动实操掌握，非语言学习；必须用的场景是编译期无法确定类型时，如动态sql生成、自定义json.marshal、依赖注入、字段接口检查；修改值须确保可寻址并调canset()；kind()判底层类型，name()返命名类型名；私有字段不可见，因反射遵循可见性规则。
reflect 不是靠“语言学习”掌握的，而是靠明确场景驱动下的反复实操。你不会因为读完十篇原理文章就突然会用反射，但写三次通用 JSON 序列化、两次结构体字段遍历、一次动态方法调用后，reflect.TypeOf 和 reflect.ValueOf 就自然长进肌肉记忆里了。
什么时候必须用 reflect？
不是“能用”，而是“不用就写不出来”。典型场景包括：
- 写一个函数，接收任意 struct，自动拼出 INSERT SQL（字段名和值都未知）
- 实现自己的
json.Marshal逻辑，要读取struct字段的json:标签 - 框架里做依赖注入：根据类型名从容器中取出实例，再塞进另一个 struct 的字段
- 测试工具里遍历所有导出字段，检查是否都实现了某个接口
这些场景共同点是：编译期无法确定类型，必须在运行时查结构、读标签、改值、调方法。
reflect.Value 修改值为什么总 panic？
因为 reflect.ValueOf(x) 返回的是 x 的副本，不可寻址、不可修改。常见错误写法：
var n int = 42 v := reflect.ValueOf(n) v.SetInt(100) // panic: cannot set value of unaddressable value
正确做法只有两个：
- 传指针：
v := reflect.ValueOf(&n).Elem()，再调SetInt - 确保原值本身可寻址（比如局部变量、切片元素、map 值——但 map 值默认不可寻址，得先
Addr()再Elem()）
判断能否修改：永远先看 v.CanSet() 返回 true 才动手。
Type.Kind() 和 Type.Name() 到底区别在哪？
这是初学者最常混淆的点：
-
t.Kind()是底层分类，比如reflect.Struct、reflect.Slice、reflect.Ptr——它不关心你定义的类型名，只关心“它本质上是什么” -
t.Name()是类型名（仅对命名类型有效），比如MyInt；未命名类型（如struct{}、[]string）返回空字符串 -
t.String()返回完整类型描述，如"main.MyInt"或"[]int"
实际编码中，分支逻辑几乎全靠 Kind()，比如处理 struct 就 if t.Kind() == reflect.Struct，而不是靠 Name() 做字符串匹配。
结构体字段遍历为什么看不到私有字段？
Go 反射严格遵循包级可见性规则：
-
v.NumField()和v.Field(i)只返回导出（大写开头）字段 - 想访问私有字段？做不到。这不是限制，而是设计原则：反射不能绕过语言本身的访问控制
- 如果你发现某个字段“消失”了，先确认它首字母是否大写；如果必须处理私有字段，说明设计可能有问题——要么暴露字段，要么提供导出方法
另外注意：v.FieldByName("Name") 返回的是新 reflect.Value，它继承原值的可寻址性；但若字段本身不可寻址（比如 struct 值副本中的字段），CanSet() 仍为 false。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
