函数参数必须使用chan类型，用于在goroutine间安全传递数据，确保并发操作时的同步与通信。
函数参数必须用 chan 或 <code> 显式声明方向
Go 编译器不会自动推断通道方向，也不会在函数调用时做隐式转换。如果你写一个只读函数但参数仍用 chan int，那它就能意外地往里写数据——这违背了单向约束的初衷。
正确做法是：所有接收通道作为输入的函数，都应明确标注方向。比如消费者函数只能读，就写成 func consumer(in ；生产者只发，就写成 <code>func producer(out chan。
- 错误示例：
func badHandler(ch chan int)—— 调用方无法从签名知道该函数是否可能写入 - 正确示例：
func goodHandler(ch —— 一眼看出只能读，且编译器会拦住任何 <code>ch 操作 - 注意：
和 <code>chan 是不同类型，不能直接赋值给 <code>chan T变量，但可由双向通道安全转换
双向通道转单向通道要靠类型转换，不是重新 make
你不能也不该用 make( 创建“原生只读通道”——这只会创建一个 nil 通道，一读就永久阻塞。真正安全的做法，是从一个已存在的双向通道（<code>chan T）出发，用类型转换生成单向视图。
例如：
立即学习“go语言免费学习笔记（深入）”；
ch := make(chan int, 10)<br>readOnly := <-chan int(ch) // 合法：转为只读视图<br>writeOnly := chan<- int(ch) // 合法：转为只写视图<br>// readOnly 和 writeOnly 都指向同一底层通道，只是访问权限被编译器限制
make( 是语法合法但语义危险的操作，结果是 nil，慎用- 转换后的单向变量仍能参与 goroutine 通信，只是编译器禁止越权操作
- 这种转换是零开销的，不涉及内存复制或运行时检查
高阶函数返回单向通道时，务必确保调用方无法绕过方向限制
当你写一个工厂函数，比如 func NewPipeline() (，返回一对单向通道，本质是把同一个双向通道拆成两个受限视图。关键在于：返回后，外部代码无法再拿到原始双向通道引用。
常见陷阱是：在函数内部还保留着双向通道变量，并意外暴露出去（比如通过全局变量、结构体字段或额外返回值），那就等于废掉了单向约束。
- 安全写法：只返回单向类型，内部用局部双向通道完成初始化，之后不再持有它
- 危险写法：返回单向通道的同时，还把原始
chan string存进某个导出字段里 - 如果要用结构体封装管道，字段本身也应声明为
或 <code>chan，而非 <code>chan T
select 语句中混用单向通道容易触发编译错误
在 select 块里，每个 case 的操作必须与通道方向匹配。比如对 执行 <code>ch 会直接报错；反过来，对 <code>chan 写 <code>v := 同样通不过编译。
这意味着：如果你把单向通道传进一个含 select 的函数，得提前确认每个 case 的操作方向是否与参数类型一致。
- 典型错误：
select { case x := 用在参数为 <code>in chan 的函数里 —— 编译失败 - 解决办法：要么改函数签名，要么重构
select逻辑，确保操作符和通道方向严格对应 - 无缓冲通道 + 单向 +
select组合时，尤其要注意 goroutine 协作节奏，否则易卡死
单向通道的价值不在运行时，而在编译期——它不改变通道行为，只收紧你的手能碰哪些操作。一旦漏掉方向声明、误用 make、或在结构体/返回值中泄露双向引用，整个约束就形同虚设。
