Go反射向channel发数据需确保val.Kind()==reflect.Chan、val.CanSend()为true且非满buffered通道；reflect.Select需手动构建含有效reflect.Value类型Chan的[]reflect.SelectCase，Dir与Send字段须匹配方向和元素类型。
Go 反射怎么往 reflect.Value 类型的 channel 里发数据
不能直接用 reflect.Send 往任意 reflect.Value 发——它只接受 chan 类型且必须是 **unbuffered 或有剩余容量的 buffered channel**，否则 panic：reflect: Send on closed channel 或 reflect: Send on nil channel。
实操前先确认三件事：
-
val.Kind() == reflect.Chan且val.IsValid()为 true -
val.CanSend()返回 true（比如不能对只读 channel 做 send） - 若 channel 是 buffered，用
val.Len() 判断是否还有空间
发送示例：
if val.Kind() == reflect.Chan && val.CanSend() {
if val.Len() >= val.Cap() && val.Cap() > 0 {
// buffered 满了，不能再 send
return errors.New("channel full")
}
val.Send(reflect.ValueOf("hello")) // 注意：传入值类型需匹配 chan 元素类型
}
Go reflect.Select 怎么动态构建 reflect.SelectCase 数组
reflect.Select 不是语法糖，它是反射版 select，但必须手动构造 []reflect.SelectCase。常见错误是把 reflect.SelectCase 的 Chan 字段设成 nil、或类型不匹配导致 panic：reflect: SelectCase Chan type must be chan。
立即学习“go语言免费学习笔记（深入）”；
关键点：
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
-
Chan字段必须是reflect.Value，且Kind() == reflect.Chan -
Dir只能是reflect.SelectSend或reflect.SelectRecv，不能混用方向 -
Send字段仅在Dir == reflect.SelectSend时生效，且值类型必须与 channel 元素类型一致 - 数组长度不能为 0，否则
reflect.Select会永久阻塞（无 default 时）
简单接收 case 构建：
cases := []reflect.SelectCase{
{Dir: reflect.SelectRecv, Chan: reflect.ValueOf(ch1)},
{Dir: reflect.SelectRecv, Chan: reflect.ValueOf(ch2)},
}
chosen, recv, ok := reflect.Select(cases)
if ok {
fmt.Println("received:", recv.Interface())
}
为什么 reflect.Select 有时不返回，或总选中第一个 case
不是 bug，是行为符合 spec：当多个 channel 同时就绪，reflect.Select 随机选一个；但如果某个 channel 是 nil，对应 case 会被忽略 —— 但很多人误以为 “nil channel 等价于 default”，其实不是。
容易踩的坑：
- 把未初始化的 channel 变量（值为 nil）传给
Chan字段 → 该 case 被跳过，可能只剩一个有效 case，看起来“总选中它” - 用
reflect.ValueOf(&ch).Elem()错误取地址 → 得到的是指针而非 channel 值，Kind()变成reflect.Ptr，触发 panic - 在循环中复用同一组
reflect.SelectCase，但其中某个Chan已被 close → 后续调用会立即返回该 case，ok == false，但没检查就继续用recv.Interface()会 panic
性能和类型安全提醒：什么情况下不该用反射处理 channel
反射操作 channel 的开销远高于原生 select：每次 reflect.Select 都要拷贝 case 数组、校验类型、做 runtime 调度判断。实测 5 个 channel 的反射 select 比原生慢 3–5 倍。
更关键的是类型擦除：
- 传入
reflect.ValueOf(ch)后，编译器无法验证元素类型是否匹配，错误发生在运行时 - 如果 channel 元素是 interface{}，反射 send 时传 int 却期望 string，panic 信息是
reflect: Call using int as type string，定位成本高 - 交叉使用反射 channel 和原生 channel（比如反射 send，原生 recv），只要类型一致就没问题；但混用
chan / <code> 方向时，<code>reflect.Value会丢失方向信息，CanSend()可能误判
真正需要反射的场景极少：比如通用消息路由中间件、测试框架模拟多 channel 协作、或者 DSL 解析器动态绑定 channel。其余情况，硬编码 select 更稳更快。
