reflect.MakeChan 必须显式传入缓冲区大小，否则编译失败或运行时 panic；类型须用 reflect.ChanOf 构造，不能直接反射已有 channel 实例。
reflect.MakeChan 创建动态 channel 的典型错误
直接用 reflect.MakeChan 创建 channel 但没传缓冲区大小，结果得到一个 nil channel —— 这是新手最常踩的坑。它不会 panic，但后续 send/receive 操作会立即死锁或 panic：send on nil channel 或 receive from nil channel。
根本原因：该函数第二个参数是 bufferSize，不是可选参数；传 0 表示无缓冲（即 sync channel），但必须显式传入，不能省略或传 nil。
- 正确写法：
reflect.MakeChan(typ, 0)（无缓冲）或reflect.MakeChan(typ, 10)（缓冲 10） - 错误写法：
reflect.MakeChan(typ)（编译不通过）或reflect.MakeChan(typ, -1)（运行时 panic：negative capacity） - type 必须是
reflect.Chan类型，用reflect.ChanOf构造，不能直接用reflect.TypeOf(make(chan int))得到的值去套用——因为那是个具体实例，不是类型描述
如何构造 reflect.Chan 类型再创建实例
你不能拿一个已存在的 channel 变量去反射出“能复用的类型”，而要从零开始描述它的类型：方向、元素类型、是否带缓冲。比如想动态建 chan，就得用 <code>reflect.ChanOf(reflect.SendDir, reflect.TypeOf("").Kind())。
-
reflect.ChanOf第一个参数控制方向：reflect.BothDir/reflect.SendDir/reflect.RecvDir - 第二个参数只能是
reflect.Kind，不是reflect.Type；所以得用reflect.TypeOf(x).Kind()，而不是直接传reflect.TypeOf(x) - 构造完
reflect.Type后，必须用reflect.MakeChan创建reflect.Value，再用.Interface()转回真实 channel —— 少这一步，你拿到的只是 Value 封装体，没法在 select 或 goroutine 中用
示例：建一个可发送的 chan：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
chType := reflect.ChanOf(reflect.SendDir, reflect.Int) chVal := reflect.MakeChan(chType, 0) ch := chVal.Interface().(chan<- int)
MakeChan 在泛型或配置驱动场景下的实际限制
如果你正试图用它实现“根据 YAML 配置自动启一堆不同类型的 channel”，得小心：Go 的 channel 类型是静态的，reflect.MakeChan 产出的 channel 无法被类型断言成任意具体类型，除非你知道原始元素类型和方向。
- 无法安全转成
chan int和chan string共用一个变量名，它们是完全不同的类型 - 若用
interface{}存储，取出来后必须用reflect.Value.Convert或二次反射操作，代价高且易错 - 性能上，每次
MakeChan+Interface()都有反射开销，不适合高频路径；纯配置驱动的 channel 管理，建议改用预定义类型 + map[string]any 分发
为什么不用 MakeChan 也能“动态”建 channel
绝大多数所谓“动态需求”，其实不需要反射。比如按字符串名创建 channel，更简单的方式是用 map 预注册：
chans := map[string]chan int{
"worker": make(chan int),
"log": make(chan int, 100),
}只有当你真需要在运行时根据未知结构（如插件系统解析出的类型签名）生成 channel，才值得碰 reflect.MakeChan。这时候务必检查：reflect.Kind 是否为 reflect.Chan、bufferSize 是否非负、方向参数是否合法——漏掉任一检查，panic 就在下一行。
