reflect.value.call 比直接调用慢50–100倍，因查哈希表、装箱、堆分配等开销；cgo单次调用慢50–200ns，主因abi切换而非c逻辑；两者叠加将引发正确性崩溃而非单纯性能问题。
reflect.Value.Call 比直接调用慢 50–100 倍
这不是估算，是反复 go test -bench 验证过的量级。每次 reflect.Value.Call 都要查类型哈希表、构造新 reflect.Value、做 interface{} 装箱、触发堆分配，还禁用内联和逃逸分析优化。你在 HTTP handler 里对每个请求都 v.MethodByName("ServeHTTP").Call(args)，它就会在 pprof 里亮得刺眼。
缓存能大幅缓解：提前用 reflect.ValueOf(obj).MethodByName("Foo") 获取一次 reflect.Value，后续复用；或更彻底地缓存 reflect.Method 的索引（reflect.TypeOf(obj).MethodByName("Foo").Index），再用 v.Call([]reflect.Value{...}) 直接调用——这样后续开销可压到纳秒级。
- 别在循环里重复调用
MethodByName，它内部是线性遍历方法表 - 传参时避免大结构体值拷贝，优先传指针并用
reflect.Value.Addr() - 如果只是固定几个方法，手写 switch/case 分发比反射稳定且快一个数量级
cgo 调用单次开销 50–200ns，但不随逻辑复杂度增长
cgo 慢的根源不是 C 代码本身，而是 ABI 切换：每次调用都要切栈、重置信号掩码、暂停 P 等待 GC 安全点。哪怕 C 函数只做 return x + 1，开销也稳在 50–200ns。这意味着高频小粒度调用（比如每帧调 1000 次 C.add_one）会直接拖垮吞吐，而非 C 实现有问题。
对比 reflect.Value.Call 的“慢在计算”，cgo 的“慢在上下文切换”——它更像穿鞋出门一趟，不管目的地是厨房还是机场，光系鞋带就要 100ns。
- 绝对不要在 for 循环里调
C.process(&item)，应改用批量接口：C.process_batch(items, len) - 避免
C.CString和C.GoString：空字符串也要 malloc+memcpy，是典型性能黑洞 - 传
[]byte给 C 时，若 C 只读，用C.CBytes(data)+ 显式长度，跳过 UTF-8 验证
两者叠加使用几乎必然出问题
Go 反射无法操作 cgo 类型：对 *C.int 调 reflect.ValueOf()，得到的是 *main._Ctype_int 这种不可穿透的占位符；Elem() 会 panic；Interface() 返回 uintptr 而非整数。这是因为 cgo 类型没有 Go 运行时所需的类型元数据，反射根本看不到字段、大小、对齐方式。
想“动态调用 C 函数”，不能靠反射去查 C.func 符号表——cgo 不导出符号，链接器都看不到。唯一可行路径是：用 C 函数桥接，比如定义 C.get_func_by_name("foo") 返回 unsafe.Pointer，再用 reflect.NewAt 构造可调用的 Go 函数值。但这要求你完全掌控 C 函数签名和调用约定，稍有错位就是段错误。
- 别尝试
reflect.ValueOf(C.some_struct).Field(0)——一定 panic - 判断是否为 cgo 类型：检查
t.Name()是否以_Ctype_开头，v.Kind() == reflect.Uintptr - 日志、序列化等通用逻辑中遇到 cgo 类型，必须提前分流，不能交给反射统一处理
真正该关心的不是“哪个更慢”，而是“哪条路根本走不通”
反射至少还能跑起来，只是慢；cgo 类型一旦混进反射流程，大概率在运行时 panic 或返回无意义值。而两者叠加（比如用反射去调一个由 cgo 注册的函数指针）会同时触发内存布局错位、ABI 不匹配、GC 生命周期失控三重风险——这不是性能问题，是正确性悬崖。
最容易被忽略的一点：cgo 分配的内存（如 C.malloc）绝不能交给 Go 的 unsafe.Slice 包装后丢给 GC；反射若误把这类切片当普通 []byte 处理，会在 GC 时回收底层指针，而 C 代码还在往已释放地址写。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
