reflect.Value.Call 本身不提供并发安全，需手动加锁保护共享状态；调用前必须检查 receiver 是否有效，避免 nil panic；高频反射应缓存 Type/Value 并预建映射表。
reflect.Value.Call 本身不提供并发安全
反射调用 Call 方法只是按签名执行函数，它不会自动加锁、也不感知共享状态。如果你在多个 goroutine 中并发调用同一个结构体的方法（尤其是修改字段的方法），而该结构体本身没做同步保护，就会触发 data race —— go run -race 会立刻报出写冲突。
常见错误场景：
- 多个 goroutine 同时对一个
SafeCounter实例调用Inc方法，但该方法是通过反射动态调用的，且底层结构体没锁 - 反射调用嵌入接口的方法（如
b.Foo()），但b.A字段为nil，不同 goroutine 同时判空+调用，仍可能因竞态导致 panic
必须把反射调用包裹在同步机制里
并发安全不是反射的责任，而是你使用反射时的职责。所有涉及共享数据读写的反射操作，都得套上同步原语。
推荐做法：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Mutex或sync.RWMutex封装整个结构体，所有公开方法（含反射入口）统一走锁逻辑 - 如果只操作某个字段或索引（比如数组元素），可用
[]sync.Mutex按需锁定对应位置，避免全局锁争用 - 对 map/slice 类型做反射修改前，先确认其底层数组/哈希表是否已被其他 goroutine 并发写入；否则即使加了锁，
reflect.Value.MapIndex或Index也可能 panic
调用前必须检查 receiver 是否有效
反射调用方法最常 panic 的原因是 receiver 为 nil，尤其在嵌入接口或指针接收者场景下。这不是并发问题，但并发会放大它。
关键检查点：
- 调用
MethodByName后，立刻判断method.IsValid() && method.CanCall() - 若 receiver 是指针类型（如
*MyStruct），需确认原始变量非nil：例如if p == nil { return errors.New("nil receiver") } - 若 receiver 是接口字段（如
type B struct { A }），必须显式判空：if b.A == nil，不能依赖MethodByName返回值是否有效
避免高频反射 + 缓存 Type/Value 结构
每次调用 reflect.TypeOf 或 reflect.ValueOf 都会遍历类型系统，开销不小。在高并发循环中反复做这些操作，不仅拖慢性能，还可能掩盖真正的竞争点。
优化建议：
- 对固定类型结构体，缓存
reflect.Type和初始reflect.Value（如字段偏移、方法索引） - 不要在 hot path 上做
FieldByName或MethodByName查找；提前建好映射表或用代码生成替代 - 如果只是取字段值，优先用
String()、Int()等专用方法，它们比Interface()更快也更安全
真正难的不是“怎么调用”，而是“谁在同时调用、改了什么、有没有人正读着”。反射让逻辑更隐晦，同步就得更显式——漏掉一次 Lock()，race detector 就会在你发版前最后一刻提醒你。
