<p>单向通道 <-chan int 和 chan<- int 是编译期强制类型约束，非语法糖；Go 编译器严格禁止向只读通道发送或从只写通道接收，提前暴露设计错误，明确协程职责边界。</p>
单向 chan<- int 和 <-chan int 不是语法糖，是编译期强制约束
Go 编译器真会拦住你往 <-chan int 里写数据，也拦住你从 chan<- int 里读 —— 这不是文档说说而已，是类型系统硬卡的。它不改变运行时行为，但能提前暴露设计错误。
常见错误现象：cannot send to receive-only channel 或 cannot receive from send-only channel，往往出现在函数参数传错方向、或类型断言后忘了转换方向时。
- 函数接收
<-chan int参数，就代表“只读”，调用方必须确保传入的是可读通道（哪怕原先是双向的，也要显式转成单向） - 用
make(chan int)创建的是双向通道；要转成单向，得靠类型转换：ch := make(chan int); rch := <-chan int(ch); sch := chan<- int(ch) - 不能直接把
chan int当作<-chan int传给函数——Go 不自动隐式转换，必须显式转型或在声明/返回时就定好方向
用单向 Channel 明确协程职责边界，避免意外关闭或重复关闭
多个 goroutine 共享一个双向 chan int，很容易出现谁关了、谁还在写、谁又试图读已关闭通道的问题。单向通道天然限定了“谁有资格关”。
使用场景：生产者-消费者模型中，生产者函数只拿到 chan<- int，消费者只拿到 <-chan int；关闭动作只能由生产者做（且只能对发送端有效），消费者无需、也不该关通道。
立即学习“go语言免费学习笔记（深入）”；
- 关闭
chan<- int是合法的，关闭后所有后续发送 panic；关闭<-chan int直接编译失败 - 消费者用
range遍历<-chan int安全，因为 range 自动感知关闭；但如果误传了双向通道且被别处关闭，逻辑仍可能出错 —— 所以关键不在通道本身，而在“谁持有发送端” - 如果函数既要读又要写，别硬塞进单向通道，说明设计没分清角色；这时候该拆成两个通道，或换其他同步机制
select 中混用单向通道不会提升性能，但能防止误操作
单向通道不影响 select 的运行效率，底层仍是同一套 runtime.channel 结构。但它让 IDE 和人一眼看出哪个 case 是发、哪个是收，减少手滑写反 <- ch 方向的概率。
参数差异：双向通道在 select 里既能写也能读；单向通道只允许匹配对应操作，否则编译不过。
- 写
case ch <- x:时，ch类型必须含chan<-；写case y := <-ch:时，ch必须含<-chan - 如果某个
case本意是接收，但传入了chan<- int，编译器立刻报错，比运行时 panic 更早发现问题 - 不要为了“看起来更安全”而强行把所有通道都改成单向 —— 如果函数内部确实需要读写，硬拆反而增加转换开销和理解成本
接口函数返回 <-chan T 是惯用做法，但要注意生命周期管理
像 time.Tick、context.WithTimeout 返回的都是 <-chan struct{} 或类似类型，这是 Go 生态的共识：对外只暴露读能力，内部实现自由控制发送与关闭。
容易踩的坑：拿到 <-chan T 后，以为“反正不能关，就不用管了”，结果生产者 goroutine 泄漏，或者通道永远不关闭导致接收方卡死。
- 返回
<-chan T的函数，通常意味着它启动了一个后台 goroutine 来发数据；调用方需自行决定何时退出监听（比如配合context） - 无法从
<-chan T恢复成双向通道，所以别指望“后面再关它”——关的动作必须由创建方完成 - 测试时若想模拟关闭，得用真实双向通道 + 显式关闭发送端，再转成
<-chan传入，否则没法触发接收端的“已关闭”路径
事情说清了就结束。单向通道的价值不在运行时，而在代码写出来那一刻，就让人没法绕过设计意图。
