请提供具体文章内容，以便我为您生成符合要求的摘要。
chan
Go 语言里 chan 和 <code> 是独立的类型，不是对 <code>chan int 的“简化写法”或“别名”。它们在类型系统中互不兼容，也不能直接赋值给对方（除非通过双向通道隐式转换）。编译器会严格检查操作：往 chan 里执行 <code> 会报错 <code>invalid operation: receive from send-only type；往 里执行 <code>ch 同样编译失败。
这种约束只在函数参数、返回值或变量声明时生效。比如你不能写 var ch chan —— 方向相反，类型不匹配。
- 双向通道
chan int可以自动转为chan 或 <code>，但反向不行 - 函数接收
chan 参数时，调用方传入 <code>chan int没问题，但传入就会编译失败 - 接口方法签名中使用单向通道（如
Send(ch chan），能强制所有实现必须只发送、不读取
生产者函数必须用 chan
典型生产者函数如 produce(nums []int, out chan，其参数类型必须是 <code>chan。这不是风格选择，而是工程必需：它让函数内部只能写、不能读，从而自然排除了误读行为，也使 <code>close(out) 成为合法且唯一的结束信号出口。
如果参数写成 chan int，函数内部就可能意外执行 ，导致死锁或逻辑混乱；更严重的是，调用方可能在生产者 goroutine 还没结束前就往通道里发数据，引发 panic。
立即学习“go语言免费学习笔记（深入）”；
-
defer close(out)必须放在 goroutine 内部，不能放在函数顶层 —— 否则通道可能在第一次out 前就被关闭 - 即使通道带缓冲（如
make(chan int, 10)），仍需 goroutine 封装，否则阻塞点不可控 - 消费者必须用
val, ok := 判断是否关闭，仅用 <code>val := 会在关闭后永久阻塞或读零值
time.Timer.C 是
time.Timer 的 C 字段声明为 ，这是 Go 标准库刻意为之的防御设计。如果它暴露为双向 <code>chan Time，外部代码就可能错误地向该通道发送值，污染计时器内部状态，导致后续 Reset 或 Stop 行为异常，甚至引发难以复现的竞态。
这个单向通道不是“只读接口”，而是“只读契约”——它把通道方向作为 API 边界的一部分，和函数签名一样具有契约效力。
- 你无法对
timer.C执行timer.C ，编译直接拒绝 - 所有标准库中返回单向通道的 API（如
context.Done()返回）都遵循同一原则 - 自定义类型若含通道字段，优先声明为单向类型，可提前拦截非法调用
单向通道不能直接 make，但可以间接构造
你不能写 make(chan 或 <code>make( —— Go 不允许直接创建单向通道实例。所有通道必须由 <code>make(chan T) 或 make(chan T, cap) 创建，得到的是双向通道；单向类型只能通过变量声明或函数参数“视图化”获得。
例如：ch := make(chan int); var sendOnly chan 是合法的；但 <code>sendOnly := make(chan 会报错 <code>syntax error: unexpected <-。
- 试图用
make(<-chan int)初始化只读通道，结果只会是编译失败 - 所谓“只读通道有意义”，前提是它背后有另一个 goroutine 在往对应的双向通道里写
- 没有 goroutine 往通道写，
<-chan就是永远阻塞的黑洞，不是设计缺陷，而是使用前提未满足
单向通道的价值不在“能做什么”，而在“阻止你做什么”。它不减少功能，而是把错误从运行时提前到编译期，且让函数意图一目了然。最容易被忽略的一点是：方向约束一旦写进函数签名，就构成了调用方必须遵守的契约 —— 这比文档说明或注释可靠得多。
