用 reflect.send 向任意 chan 发送值前必须确认方向：go 的反射不能绕过通道的方向性检查，若 reflect.value 底层是 chan t、chan
用 reflect.Send 向任意 chan 发送值前必须确认方向
Go 的反射不能绕过通道的方向性检查。如果你拿到一个 reflect.Value 类型的通道，它底层是 chan T、chan 还是 <code>，会直接影响能否调用 <code>Send 或 Recv。
常见错误现象：panic: reflect: Send using unidirectional chan type *int —— 实际上不是类型问题，而是你传入的是 （只读），却调用了 <code>Send。
- 用
v.Kind() == reflect.Chan只能确认是通道，不区分方向 - 真正判断方向得靠
v.Type().ChanDir()：返回reflect.BothDir、reflect.SendDir或reflect.RecvDir - 只有
reflect.SendDir或reflect.BothDir才能安全调用v.Send(x) - 如果原始变量声明为
ch := make(chan，反射后 <code>v.Type().ChanDir()就是reflect.SendDir，不能Recv
reflect.Select 是唯一能反射式处理多路通道操作的方式
你没法用 reflect.Value 拼出原生 select 语句，但 reflect.Select 提供了等价能力——它接受 []reflect.SelectCase，每个 case 对应一个通道操作（send/recv）和可选的值。
使用场景：写泛型通道调度器、动态构建工作流、测试中模拟竞态行为。
立即学习“go语言免费学习笔记（深入）”；
-
reflect.SelectCase.Dir必须设为reflect.SelectSend或reflect.SelectRecv，不能混用 - 发送 case 的
Send字段必须是reflect.Value，且类型要与通道元素类型匹配（否则 panic） - 接收 case 的
Recv字段在返回时才有效，调用前留空即可 - 如果所有通道都阻塞且没 default case，
reflect.Select会阻塞，和原生select一致
示例片段：
cases := []reflect.SelectCase{<br> {Dir: reflect.SelectRecv, Chan: reflect.ValueOf(ch1)},<br> {Dir: reflect.SelectSend, Chan: reflect.ValueOf(ch2), Send: reflect.ValueOf(42)},<br>}
反射收发时类型不匹配会导致 panic，而非编译错误
原生 Go 编译期就卡死类型不匹配的通道操作，但反射把这层检查推迟到运行时。一旦 reflect.Value 的类型和通道元素类型不一致，Send 或 Recv 立即 panic，信息类似：reflect: Send of int to chan string。
- 别依赖
v.Type().Elem()和你要发的值类型“看起来一样”——比如type MyInt int和int是不同类型 - 发送前用
sendVal.Type().AssignableTo(recvChan.Type().Elem())做兼容性检查更稳妥 -
Recv返回的reflect.Value默认是不可寻址的；若需修改内容（比如解包结构体字段），得用.Interface()转回原生值再操作 - 注意 nil 通道：对 nil
reflect.Value调用Send/Recv会直接 panic，和原生行为一致
性能差是反射操作通道的硬伤，别在热路径用
每次 reflect.Send 或 reflect.Select 都涉及类型擦除、接口转换、运行时类型校验，实测比原生通道操作慢 10–100 倍，且 GC 压力明显上升。
容易被忽略的地方：即使你只在初始化或配置阶段用反射建通道拓扑，只要后续高频调用 reflect.Value.Send，就等于把热路径拖进反射泥潭。
- 如果目标只是“统一收发接口”，优先考虑函数值封装：
func(interface{})+ 类型断言，比反射快得多 - 需要动态类型适配时，用代码生成（
go:generate）代替运行时反射，把类型分支提前展开 -
reflect.Select内部会复制所有 case 的reflect.Value，大量 case 时开销陡增，5 个以上 case 就该警惕
事情说清了就结束。
