Go语言中channel的“方向”是编译期类型约束而非运行时行为，即
Go 语言中 channel 的“方向”不是运行时行为，而是编译期类型约束——chan 和 <code> 不是新通道，而是对同一个底层 <code>chan int 的类型视图限制。它不改变通道能力，只限制你 *能怎么用*。
为什么 make(chan 会编译失败？
因为 Go 禁止直接用 make 创建单向通道。所有通道的底层实现都必须可读可写，否则无法通信。单向类型只能从双向通道派生而来。
make(chan 或 <code>make( 是非法语法，编译器直接报错- 正确起点永远是
c := make(chan int, N) - 单向视图必须通过赋值或类型转换生成：
s := (chan 或 <code>r := - 试图对
chan 类型变量执行 <code>（接收）会触发编译错误：<code>invalid operation: receive from send-only type
chan 和 <code> 在函数参数中怎么用？
这是单向通道最常见、最有价值的场景：把操作权限“锁死”在接口契约里，让调用方无法误操作。
- 发送函数只接受
chan：确保它只能发，不能收（哪怕传入的是双向通道，函数体内也看不到接收能力） - 接收函数只接受
：确保它只能收，不能发 - Go 会自动把双向通道隐式转换为对应单向类型，无需显式转换（但显式更清晰）
- 示例：
func worker(in —— 调用者传 <code>ch即可，worker 内部根本没法往in写
什么时候该用单向通道？什么时候不该？
单向通道的价值只在「多人协作」或「库/接口设计」时才真正体现。日常写脚本或小工具，用双向通道完全没问题。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 应该用：定义公共函数签名、封装 SDK 接口、写 goroutine 工厂函数（如启动生产者/消费者）、配合
range安全遍历 - ❌ 不该用：试图靠单向通道“防止别人关 channel”——关闭权限不受方向约束，
close()只认底层通道；也不该用它做限流（那是chan struct{}的事） - ⚠️ 注意：
time.Timer.C是，这是标准库强制只读的典型例子——避免外部误塞数据破坏计时逻辑
常见坑：range 遍历时忘记关闭通道
单向通道常和 for v := range r 搭配使用，但这个循环退出唯一条件是通道被关闭。如果发送方没调用 close()，接收协程会永久阻塞。
- 只有发送方（或明确负责结束的一方）应该调用
close()；接收方 close 会 panic - 用
defer close(ch)在 sender 函数末尾确保关闭，比裸写close()更安全 - 别在接收端用
for { select { case v, ok := 手动判断——既啰嗦又容易漏掉 <code>break外层循环 - 记住：
range自动处理关闭信号，是最简洁、最不易出错的方式
