go反射是受约束的运行时工具，误用会panic或静默失败；传值仅得副本，传指针+elem()才可修改原值；结构体字段须导出、方法调用前须校验isvalid和cancall；kind判类型、type获名称；性能差，仅适用于框架层等非热路径场景。
Go反射不是万能胶，也不是语法糖，它是一套有明确约束的运行时操作工具——用错地方会 panic，绕开规则会静默失败。
reflect.ValueOf 传值 vs 传指针的区别
传普通变量（如 int、string）给 reflect.ValueOf，返回的是该值的副本；传指针（&x），才能后续修改原值。这是最常踩的坑：你以为能改，其实改的是副本。
-
reflect.ValueOf(x).CanSet()永远返回false，因为值不可寻址 -
reflect.ValueOf(&x).Elem().CanSet()才可能为true，前提是x本身不是字面量或常量（比如不能对reflect.ValueOf(&42).Elem()调用SetInt） - 结构体字段要可导出（首字母大写）才能被反射读写，否则
CanSet()为false，即使你传了指针
动态调用方法前必须检查 IsValid 和 CanCall
反射调用方法不是“有名字就能调”，它依赖接收者类型和方法签名严格匹配。忽略校验会导致 panic 或静默跳过。
-
v.MethodByName("Foo").IsValid()只说明方法存在，不保证可调用（比如接收者是值类型，而你传的是指针） -
method.CanCall()必须为true才能安全执行method.Call() - 参数必须是
[]reflect.Value类型，每个元素需与目标方法参数类型一致；类型不匹配不会编译报错，但运行时 panic - 如果方法有返回值，
Call()返回的是[]reflect.Value，需手动取[0].Interface()转回原类型
Kind 和 Type 的混淆导致字段遍历失败
用 reflect.Kind() 判断基础类型（struct、slice、ptr 等），用 reflect.Type() 获取具体类型名（如 MyStruct）。混用会导致 NumField() 或 Len() 调用失败。
-
v.Kind() == reflect.Struct是遍历字段的前提，但v.Kind() == reflect.Ptr时需先v.Elem()才能访问底层 struct -
v.Type().Name()对匿名字段或内建类型（如int）返回空字符串，应优先用v.Type().String()或v.Kind() - 对 slice、map、chan 等复合类型，必须用
v.Len()、v.MapKeys()等对应方法，不能直接用v.NumField()
反射性能开销和适用边界
反射比直接调用慢 10–100 倍，且无法被编译器内联或优化。它不该出现在热路径里，只适合框架层、配置解析、序列化等“一次初始化、多次使用”的场景。
- 避免在循环中反复调用
reflect.TypeOf或reflect.ValueOf，缓存reflect.Type和reflect.Value实例 - JSON 序列化用
encoding/json内置反射已足够，自己手写反射 marshaler 通常得不偿失 - 依赖注入、ORM 映射这类通用逻辑才值得抽象反射，业务逻辑里硬编码结构体字段更清晰、更安全
真正难的不是学会怎么调 CanSet 或 MethodByName，而是判断什么时候**不该用反射**——当你要写 if-else 分支处理三种结构体时，反射可能是捷径；当你需要每秒处理十万条日志并动态提取字段时，它就是瓶颈。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
