反射不应初学时线性学习，而应在遇到通用序列化、动态配置绑定等具体问题时目标驱动学习；reflect.TypeOf返回只读元数据，reflect.ValueOf返回可操作值容器但默认不可写；判断类型行为应优先用Kind()而非Name()。
先说结论：反射不该是初学阶段“按顺序学”的内容，而应是遇到具体问题（比如通用序列化、动态配置绑定、ORM字段映射）时，带着目标倒逼学习的工具。盲目按“Type→Value→Kind→Set→Call”线性学，90%的人会在 reflect.ValueOf(x).Elem() 这一步卡死，然后放弃。
什么时候该开始碰反射？
不是语法写熟了就该学反射，而是你明确遇到了以下任一场景：
- 要写一个能自动把
map[string]interface{}填充进任意结构体的函数 - 想实现类似
json.Unmarshal那样，不改代码就能支持新 struct 的校验器 - 在写 CLI 工具，需要根据 struct 字段 tag 自动生成 flag 参数
- 正在封装数据库层，希望用结构体字段名自动映射到 SQL 列名，而不是手写
"name = ?"
没碰到这些？先放下反射，去练并发和 HTTP 中间件——它们才是 Go 日常开发的高频区。
reflect.TypeOf 和 reflect.ValueOf 的本质区别是什么？
很多人混淆这两个函数，以为只是“类型 vs 值”的表面对应。其实关键在于：reflect.TypeOf 返回的是只读元数据（不能改结构），reflect.ValueOf 返回的是可操作的运行时值容器（但默认不可写）。
立即学习“go语言免费学习笔记（深入）”；
-
reflect.TypeOf(x)：返回reflect.Type，能查字段名、tag、方法列表，但不能读/写字段值 -
reflect.ValueOf(x)：返回reflect.Value，能读字段值；只有传入指针（如&s）并调用.Elem()，才可能写字段 - 常见错误：
reflect.ValueOf(s).FieldByName("Name").SetString("foo")—— 会 panic 报cannot set unaddressable value，因为s是值拷贝，不可寻址
package main
import (
"fmt"
"reflect"
)
type User struct {
Name string
Age int
}
func main() {
u := User{Name: "Alice", Age: 25}
v := reflect.ValueOf(&u).Elem() // 必须传指针再 Elem()
if nameField := v.FieldByName("Name"); nameField.CanSet() {
nameField.SetString("Bob")
}
fmt.Println(u) // {Bob 25}
}
为什么 Kind 比 Name 更重要？
Go 的类型系统里，type MyInt int 和 int 是不同名字（Name() 返回 "MyInt" vs "int"），但底层种类（Kind()）都是 int。反射中几乎所有判断逻辑（比如“是不是数字”“是不是结构体”“能不能遍历”）都该用 Kind()，而不是 Name()。
- 用
Name()判断类型：容易漏掉自定义类型，比如type Status int不等于"int" - 用
Kind()判断行为：所有Kind() == reflect.Struct的都能用NumField()遍历 - 典型坑：
v.Kind() == reflect.Ptr时，必须先v.Elem()才能访问指向的值；直接v.Field(0)会 panic
反射真正的门槛不在 API 多难记，而在于它强制你直面 Go 的内存模型：可寻址性、指针语义、导出规则。一个字段首字母小写，反射就完全看不到；传值不传指针，就永远没法修改。这些不是反射的缺陷，是 Go 类型安全的体现——别想着绕过去，得顺着它写。
