单向通道是编译期强制的类型约束，非语法糖；函数参数必须用 chan 是为确保通道方向安全，防止非法读写操作，编译器据此校验并提前报错。
单向通道不是语法糖，是编译期强制的类型约束——用错方向会直接报错，不是运行时 panic。
为什么函数参数必须用 chan 或 <code>
双向通道 chan int 在函数里既可发又可收，但流水线各阶段职责必须隔离：生产者不该能读，消费者不该能写。如果参数用双向通道，调用方可能误操作，比如在只该发送的函数里写了 ，编译器无法拦截。
- 用
chan 作参数 → 函数体内只能执行 <code>ch ，<code> 编译失败 - 用
作参数 → 函数体内只能执行 <code>x := ，<code>ch 编译失败 - 函数签名即契约：看到
func stage1(out chan 就知道这函数只输出、不消费
make(chan T) 创建的是双向通道，怎么转成单向？
不能直接声明单向通道变量并用 make 初始化；必须从双向通道“转换”而来。Go 允许隐式转换：双向通道可安全转为对应方向的单向通道，反之不行。
- 正确写法：
ch := make(chan int); sendOnly := ch（ch是chan int，赋值给chan 类型变量自动转） - 错误写法：
var sendOnly chan → 编译报错，<code>make不接受单向类型 - 常见模式：在主流程创建双向通道，按需转为单向传入各 stage 函数
流水线中多阶段串联时，通道方向怎么衔接？
每个 stage 的输入和输出通道方向必须严格匹配：前一阶段的输出通道（chan）要连到后一阶段的输入通道（<code>）。中间不能靠类型断言或强制转换绕过检查。
- stage1 输出
chan → stage2 输入必须是 <code> - stage2 输出
chan → stage3 输入必须是 <code> - 如果某 stage 需要同时读写（比如带缓存的中间处理），它应该自己创建新通道，而不是复用上游的双向通道——否则破坏了单向性契约
容易被忽略的关闭时机与方向限制
只有发送方能安全调用 close()，而 close 只对双向或发送方向通道合法。接收方若误调 close(ch)（ch 是 ），编译直接拒绝。
- 关闭动作必须发生在最后一个发送者退出前，且只能由发送端发起
-
range循环只适用于类型，因为它是只读的；对 <code>chan 用 <code>range会编译失败 - 别指望用单向通道规避 close 逻辑——它只是帮你提前暴露错误，真正的关闭责任仍在业务逻辑里
单向通道的价值不在节省几行代码，而在把“谁该读、谁该写”的约束刻进类型系统里。一旦写错方向，编译器立刻打断，而不是等程序跑起来卡死或 panic。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
