reflect.select 不能复用未重置的 reflect.selectcase 切片，每次调用前必须重置 chan 和 send 字段，否则可能返回 -1 或 panic；chan 必须是可寻址的 reflect.value，send 需每次显式更新，且性能远低于原生 select。
go 里 reflect.Select 不能直接复用 reflect.SelectCase 切片
你写完一个 []reflect.SelectCase，想循环调用 reflect.Select 复用它？不行。每次调用前必须重置每个 SelectCase 的 Chan 和 Send 字段 —— 因为 reflect.Select 内部会“消费”掉已就绪的 channel 操作状态，且不自动恢复。
-
reflect.SelectCase不是只读描述符，它是带状态的运行时操作单元 - 如果复用未重置的切片，第二次调用大概率返回
-1（超时）或 panic：「send on closed channel」（尤其Send != nil时） - 常见于轮询多个 channel、实现带 fallback 的超时 select 场景
动态构建 reflect.SelectCase 时，Chan 必须是 reflect.Value 类型的 chan
传错类型会导致 panic：「reflect: Select using unaddressable value」或「invalid memory address」。不是 Interface{}，不是 *chan T，更不是 chan T 原值 —— 必须是 reflect.ValueOf(ch) 且该 value 本身可寻址（对 recv 是必须的，对 send 则要求 channel 未关闭且可写）。
- 接收 case：
reflect.SelectCase{Dir: reflect.SelectRecv, Chan: reflect.ValueOf(ch)} - 发送 case：
reflect.SelectCase{Dir: reflect.SelectSend, Chan: reflect.ValueOf(ch), Send: reflect.ValueOf(v)} - 默认 case：
reflect.SelectCase{Dir: reflect.SelectDefault}，此时Chan和Send必须为零值（reflect.Value{}） - 若
ch是 nil 或已 close，对应 case 会被立即忽略（recv 永不就绪，send panic），但不会导致整个reflect.Select失败
reflect.Select 返回后，Send 值不会自动清空，下次复用需手动重置
这是最隐蔽的坑：你在一个循环里反复用同一个 reflect.SelectCase 变量，第一次 send 成功后，它的 Send 字段仍持有上一次的 reflect.Value；第二次调用时若没更新 Send，就会尝试重复发送同一值 —— 轻则阻塞（channel 满），重则 panic（channel 已关）。
- 安全做法：每次构造 case 前，显式赋新值：
case.Send = reflect.ValueOf(nextVal) - 不要试图复用
reflect.Value实例，尤其是来自不同变量的reflect.ValueOf(&x)—— 它们可能绑定不同底层内存 - 如果 send 值是临时结构体或大对象，注意避免意外反射拷贝放大 GC 压力
性能敏感场景下，reflect.Select 比原生 select 慢 5–10 倍，且无法内联
原生 select 是编译期静态生成状态机，而 reflect.Select 是运行时遍历、锁 channel、调度 goroutine 的完整路径。它本质是「反射版 select 黑盒」，没有编译器优化空间。
立即学习“go语言免费学习笔记（深入）”；
- 单次调用开销约 200–500ns（视 case 数量），远高于原生 select 的 ~20ns
- 所有 case 的
Chan都会被reflect.Value封装，触发额外接口转换和类型检查 - 仅在真正需要「case 数量动态决定」时使用（如插件系统监听 N 个未知 channel），否则优先用代码生成或固定长度 slice + 原生 select 分支
事情说清了就结束。真正难的不是怎么写对，而是想清楚——这个 select 动态性，是不是非反射不可。