go反射应严格限制在泛型不支持或需深度结构检查的场景，入口仅用reflect.typeof和reflect.ValueOf，遵守导出性规则，避免运行时错误和性能损耗。
从 reflect.TypeOf 和 reflect.ValueOf 开始，别碰 reflect.kind 和 reflect.Type 的深层方法
反射不是用来“动态调用任意函数”的玩具，而是为泛型还不支持时（Go 1.18 之前）或需要深度结构检查的场景服务。新手第一课必须卡死在两个入口函数：直接传值进去，看它吐出什么。
-
reflect.TypeOf(x)返回的是reflect.Type接口，只管类型元信息——比如是不是指针、字段名有哪些、有没有实现某个接口；但它不告诉你值本身 -
reflect.ValueOf(x)返回的是reflect.Value，才真正承载值；但注意：如果传的是非导出字段（小写开头），Value.Field(i)会 panic，不是返回零值 - 别一上来就查文档翻
reflect.Kind()和reflect.Type.Kind()区别——前者是底层表示（Ptr/Struct），后者是用户定义类型名；90% 的初学者混淆都发生在这里
用 json.Marshal 对比理解反射的“可导出性”边界
Go 反射和序列化共享同一套可见性规则：只有首字母大写的字段才能被读取或设置。这不是反射的限制，是语言设计决定的。
type User struct { Name string `json:"name"` age int `json:"age"` // 小写，json 不输出，reflect 也读不到 } u := User{Name: "Alice", age: 30} v := reflect.ValueOf(u) fmt.Println(v.NumField()) // 输出 1，不是 2- 运行时无法绕过这个限制——
unsafe也不行，因为反射 API 明确检查canAddr和isExported - 调试时想看私有字段？老实用
dlv或打印%+v，别指望反射 - 如果你真需要“穿透”，说明设计有问题：要么改成导出字段 + 私有 setter，要么用组合代替嵌入
避免在循环里反复调用 reflect.ValueOf 或 reflect.TypeOf
这两个函数开销不小，尤其是 ValueOf 涉及接口转换和内存分配。新手常写成这样：
for _, item := range items { v := reflect.ValueOf(item) // 错！每次新建 reflect.Value if v.Kind() == reflect.Ptr { v = v.Elem() } // ... }- 高频路径（如 http 中间件、gRPC 拦截器）中，应提前缓存
reflect.Type和reflect.Value的零值模板 - 更推荐方案：用一次反射提取结构信息后，生成具体类型的处理函数（类似
sqlx的 struct scanner），而不是每轮都反射 - 一个简单判断：如果代码里出现
for { reflect.ValueOf(...) }，基本可以确定要重构了
别用反射替代接口，尤其不要为了“通用日志打印”上反射
看到别人用反射遍历 struct 打日志，就以为这是标准做法？其实绝大多数情况，实现 fmt.Stringer 更安全、更快、更可控。
立即学习“go语言免费学习笔记（深入）”；
func (u User) String() string { return fmt.Sprintf("User{Name:%q}", u.Name) // 明确控制输出，不暴露 age }- 反射日志的问题：字段顺序不确定、嵌套深了 panic、时间/错误等类型输出不可读、无法过滤敏感字段
- 真正需要反射的场景很窄：ORM 字段映射、配置自动绑定、测试辅助（如 deep equal 的 diff）、自动生成 protobuf 结构
- Go 生态里成熟库（
encoding/json,database/sql）内部用反射，但对外都封装成了类型安全的接口——这才是你应该学的抽象方式
反射最危险的地方不在语法，而在于它把编译期能发现的错误（字段不存在、类型不匹配）拖到运行时；而且一旦出错，堆栈里全是 reflect.Value.Call，根本看不出原始调用点在哪。先写够 10 个不用反射的版本，再决定哪一行真的绕不开它。