go反射在高性能场景下必须从热路径剥离，预缓存type与字段索引、用fieldbyindex替代fieldbyname、严格校验canset/isvalid/caninterface，仅在json序列化、orm等必要场景使用。
在极高运行性能要求下，Go反射不是“能不能用”的问题，而是“在哪用、怎么封、谁兜底”的问题。它无法被泛型或代码生成完全替代，但直接裸用 reflect.ValueOf 和 FieldByName 必然拖垮吞吐——关键在于把反射操作从热路径里摘出来，压到初始化阶段或缓存层。
避免在循环中调用 reflect.ValueOf 和 FieldByName
这是最常见也最伤性能的写法。每次 reflect.ValueOf(x) 都会分配约96字节的 reflect.Value 实例；FieldByName("ID") 则是线性遍历字段名做字符串比对，100个字段就要比100次。
- 错误示例：
for _, item := range items { v := reflect.ValueOf(item); id := v.FieldByName("ID").Int() } - 正确做法：启动时预计算
reflect.Type和字段索引，用FieldByIndex替代FieldByName - 缓存结构推荐：
sync.Map存reflect.Type → map[string]int，键是字段名，值是FieldByIndex所需的整数切片（如[]int{0}） - 注意：
reflect.Type本身可作 map key，无需转成字符串，避免额外分配
CanSet() 不只是安全检查，更是修改原值的前提条件
对非指针值调用 reflect.ValueOf(x) 得到的是副本，CanSet() 永远返回 false；只有传入指针并调用 Elem() 才能真正修改原值。漏掉 CanSet() 就直接 SetInt()，会 panic 报错 reflect: reflect.Value.SetXxx using unaddressable value —— 错误信息不带行号，只提示包名，排查成本极高。
- 必须先判断：
v := reflect.ValueOf(&x).Elem(); if !v.CanSet() { return } - 若输入是
interface{}，需先确认底层是否为指针类型，再决定是否Elem() - 对结构体字段赋值前，也要逐层检查
v.Field(i).CanSet()，小写字段默认不可设
用 IsValid() 和 CanInterface() 做前置防护，别等 Interface() 才崩
FieldByName 找不到字段时返回零值 reflect.Value，不是 nil；此时调用 Interface() 会 panic：call of reflect.Value.Interface on zero Value。这个 panic 不提示字段名、不提示结构体类型，只报位置在 reflect 包内。
- 每次取字段后必须先检查：
if !val.IsValid() { return } - 再检查：
if !val.CanInterface() { return }（CanInterface()比CanAddr()更严格，但Interface()要求它） - 如果只是要取基础类型值，优先用
String()、Int()、Bool()等专用方法，它们对零值有合理 fallback，不会 panic - 对
map或slice元素做反射操作时，记得先MapIndex()或Index()，再检查IsValid()
哪些场景真该用反射，哪些其实不该
反射不是“灵活”的代名词，它是编译期信息缺失时的兜底方案。泛型能覆盖的、类型集固定的、或可通过代码生成预处理的，都不该上反射。
- 真正需要反射的场景：
encoding/json序列化、ORM 字段映射（含gorm:"column:name"）、YAML/TOML 配置加载、tag 校验（如validate:"required,email"）、测试断言库的深层比较 - 不该用反射的场景：日志字段提取（只针对 3 种 struct）、容器通用操作（可用泛型）、简单类型转换（可用类型断言或 switch type）
- 高频路径中禁止出现
reflect.Value.Interface()—— 它触发堆分配 + 类型检查，实测比直接类型断言慢 20–50 倍 - 最易被忽略的一点：
reflect.TypeOf(nil)返回零值Type，后续调用.Kind()或.Name()会 panic，必须先if t != nil
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
