反射调用时传入 chan 类型参数必须显式包装为 reflect.Value，因 Go 反射不识别通道的“语法糖”写法如 chan int、chan。
反射调用时传入 chan 类型参数必须显式包装为 reflect.Value
Go 反射不识别通道的“语法糖”写法，chan int、chan、<code> 都是独立类型，反射中必须严格匹配。直接把原始 channel 变量塞进 <code>[]reflect.Value 会 panic，因为缺少类型擦除后的运行时表示。
正确做法是用 reflect.ValueOf(ch) 包装——注意不是 &ch，除非函数签名明确要求 *chan T。常见错误包括：
- 误把
make(chan int, 1)字面量直接传给reflect.ValueOf：它可被包装，但后续Call()时若函数期望已关闭或带缓冲的 channel，行为可能不符合预期 - 忽略方向性：函数定义为
func(，却传入 <code>reflect.ValueOf(make(chan int))（双向），虽能过类型检查，但运行时可能 panic 或死锁 - 对 nil channel 调用
reflect.ValueOf(nil)得到零值，IsValid()为 false，Call()前未校验会直接 panic
reflect.Value 传 channel 参数时需手动校验方向与缓冲状态
反射无法自动推断 channel 方向（send-only / receive-only）或缓冲容量，这些信息只存在于函数签名中。你得先用 reflect.TypeOf(fn).In(i) 拿到第 i 个参数类型，再判断其 Kind() 是否为 reflect.Chan，然后用 ChanDir() 获取方向：
-
reflect.BothDir：对应chan T -
reflect.SendDir：对应chan -
reflect.RecvDir：对应
若函数要求 ，而你传了 <code>reflect.ValueOf(make(chan int))，Go 运行时不会报错，但 channel 写入操作在调用方会被静默丢弃，极易引发逻辑 bug。缓冲容量同理：函数内部做非阻塞 select，而你传的是无缓冲 channel，就会卡住。
立即学习“go语言免费学习笔记（深入）”；
反射调用含 channel 的函数后，返回值中的 chan 不能直接用 Send/Recv
反射调用返回的 []reflect.Value 中，若某项是 channel 类型，它只是该 channel 的一个副本（底层指针相同），但 reflect.Value 本身不提供 Send、Recv 方法。你必须先用 .Interface() 转回原生 channel，再操作：
results := fnVal.Call(args)
if results[0].Kind() == reflect.Chan {
ch := results[0].Interface().(chan int) // 类型断言要小心
ch <- 42 // 正常发送
}这里有两个关键点：
-
.Interface()返回interface{}，必须做类型断言才能使用；断言失败会 panic，建议先用results[0].Type()校验类型是否匹配 - 若 channel 是
，断言成 <code>chan int会失败；应断言为<-chan int，否则编译不过 - 反射返回的 channel 值不可寻址（
CanAddr() == false），不能对其取地址或做指针运算
闭包捕获的 channel 在反射中不可见，也不能被修改
如果目标函数是闭包，且内部捕获了外部 channel 变量（如 func() { ch ），反射无法访问或替换这个捕获的 channel。你只能反射调用整个闭包，但无法干预其内部使用的 channel 实例。
更隐蔽的问题是：若闭包参数列表含 channel，而你在反射调用时传了新 channel，它只影响参数传入，不影响闭包体内部硬编码的 channel。这种混合使用容易导致数据流向混乱，调试困难。真正需要动态注入 channel 的场景，应改用显式参数传递，而非依赖闭包捕获。
最易被忽略的是：channel 的生命周期和 goroutine 安全性完全脱离反射控制。反射调用本身不启动 goroutine，但若函数内部启动了监听该 channel 的 goroutine，你必须确保 channel 在调用后仍有效，否则会 panic 或泄露 goroutine。
