reflect.Select 在 tight loop 中频繁调用会显著拖慢程序，因其每次调用都触发反射值构造、切片分配和类型检查，导致 GC 压力剧增；它不是 select 语句的运行时平替，90% 的动态监听需求可用中介 channel + 转发 goroutine 更轻量替代。
reflect.Select 在 tight loop 中频繁调用会显著拖慢程序
它不是 select 语句的运行时平替，每次调用都触发反射值构造、切片分配和类型检查。实测在 100 个 channel 上每秒调用 1000 次 reflect.Select，runtime.mallocgc 占比可达 15%+，GC 压力肉眼可见。
常见错误现象：把 reflect.Select 放进事件分发主循环里轮询，以为“只是换种写法”，结果 CPU 没跑满，内存先爆了。
- 每次调用都会新建
[]reflect.SelectCase，即使 channel 列表完全没变 -
reflect.ValueOf(ch)不是零开销——哪怕 ch 是同一个变量，每次都要重新封装 - 不能复用
reflect.Value跨 goroutine，所以预构建切片也救不了高频路径
channel 动态增删时重建切片的成本远超单次调用
真正昂贵的不是 reflect.Select 本身，而是列表变化时被迫重做整个 []reflect.SelectCase：新增要追加 reflect.SelectCase{Dir: reflect.SelectRecv, Chan: reflect.ValueOf(ch)}，删除则需切片重排或标记跳过。
使用场景多见于连接管理（如 WebSocket 网关按用户 ID 绑定/解绑 channel），但若每秒增删 > 10 次，性能就明显滑坡。
- 并发增删必须加锁或原子操作保护切片，进一步延长关键路径
- 误在
reflect.Select返回后直接修改正在监听的切片，会 panic："slice changed after Select" - 可用
map[uintptr]reflect.SelectCase缓存已封装的 case（key 用uintptr(unsafe.Pointer(&ch))），但需配套处理 channel 关闭后的地址复用问题
别把它当“动态 select”用，大多数时候你根本不需要它
90% 的所谓“动态监听 N 个 channel”需求，其实只是想统一收口消息——这时候 reflect.Select 是杀鸡用牛刀。
常见错误现象：看到 channel 数量不固定，第一反应就是上反射，结果代码难读、难测、难调，还慢。
- 更轻量的替代方案是中介 channel + 转发 goroutine：
go func(c chan T) { for v := range c { agg - 如果 channel 数量稳定且 ≤ 10，可提前构建切片并复用，但注意
Chan字段仍需每次reflect.ValueOf(ch) -
reflect.Select不支持default分支，也不能混合SelectSend和SelectRecv在同一调用中——它只做一件事：等任意一个 recv 或 send 就绪
recv.IsValid() 必须判断，否则极易 panic
reflect.Select 返回的是 reflect.Value，不是原始类型；channel 关闭后 .Recv() 返回零值且 .IsValid() == false，漏判就会 panic。
使用场景中常忽略这点，尤其在长生命周期的监听逻辑里，channel 关闭是常态而非异常。
- 所有
recv.Interface()前必须加if recv.IsValid() -
ok返回值只表示是否从非关闭 channel 收到值，不等于recv.IsValid()—— 两者语义不同，不能混用 - 传入
nilchannel 不会跳过该分支，而是直接 panic，不像原生select那样静默忽略
实际用起来最易被忽略的点是：你几乎永远不该在性能敏感路径里裸调 reflect.Select。它存在的意义是兜底，不是主力。真要动态监听，优先考虑转发 goroutine + 固定 channel，或者用位图管理预分配 slot——反射不是银弹，只是最后一道门。
