<p>单向通道是编译期类型约束，不是运行时权限，Go 语言中通过 chan<- 和 <-chan 实现发送和接收方向的静态类型限制。</p>
单向通道不是运行时权限，是编译期类型约束
Go 的 chan 和 <code> 不改变底层通道行为，也不限制 goroutine 间实际通信能力。它只在编译时检查你「当前变量能做什么」：对 <code>chan 变量执行 <code> 会直接报错 <code>invalid operation: receive from send-only type；对 执行 <code>ch 同样编译失败。
这和数据流语言（如 Elixir 的 Flow、Kotlin 的 Flow）中基于运行时订阅/发射控制的“权限”完全不同——Go 没有 runtime-level 的读写拦截，所有约束都在类型系统里完成。
- 单向类型不生成新通道，只是同一底层通道的不同“视图”
- 只要持有原始双向通道，就能绕过所有单向限制（比如用
chan int变量往传给消费者的写） - 真正起作用的前提是：你只把单向变量暴露出去，不泄露双向引用
函数参数中用 chan 或 <code> 才有意义
单独声明 var ch chan 或用 <code>make(chan 创建单向通道，几乎没用：前者无法接收，后者无法发送，且都不能被 close（<code>close() 要求至少是 chan 类型）。
唯一合理且高频的使用场景，是函数签名中限定参数方向：
立即学习“go语言免费学习笔记（深入）”；
func producer(out chan：确保调用者传入的通道，在函数体内只能发不能收func consumer(in ：确保函数体内只能收不能发，哪怕传进来的是 <code>chan int- Go 会自动把双向通道隐式转换为对应单向类型，无需显式转型
close() 权限只看底层是否可写，和变量方向无关
关闭通道的权限不由变量声明方向决定，而由该变量是否具备发送能力决定。也就是说：
-
close(ch)允许用于chan T和chan 类型变量 -
close(ch)对类型变量会编译失败：<code>cannot close receive-only channel - 即使你把一个双向通道转成
后再传给另一个函数，只要原通道还在，仍可被关闭——单向视图不阻断 close 能力
所以别指望单向通道“防止别人关”，它防不住；它只防你在错误上下文中误写 或 <code>ch 。
测试中构造只读/只写桩时，make(chan 是合法但需桥接
单元测试里确实有用到 make(chan 的场景，比如验证某个函数是否严格遵守只写契约。但它不能直接用于 <code>range 或接收操作，必须通过额外 goroutine + 双向通道桥接：
ch := make(chan<- string, 1)
results := make([]string, 0, 1)
done := make(chan struct{})
go func() {
defer close(done)
bidir := make(chan string, 1)
go func() { for s := range bidir { results = append(results, s) } }()
// 把 ch 的写入转发到 bidir
ch = chan<- string(bidir) // 注意：这里需要类型转换才能赋值
}()
// 然后调用被测函数：processItems(items, ch)
这种写法合法但繁琐，日常开发中更推荐直接用双向通道 + 单向参数，测试时传真实 chan string 并检查行为，而非执着于“纯单向通道实例”。
最容易忽略的一点：单向通道的价值，完全取决于你是否在接口边界上坚持只暴露单向引用。一旦某处不小心把双向通道变量传出去，整个约束就失效了。
