<p>Go中单向channel通过编译期类型系统强制约束方向：双向chan T可显式转为<-chan T（只读）或chan<- T（只写），不可逆；函数参数声明方向后，传入不匹配类型会编译报错，确保goroutine职责分离与类型安全。</p>
怎么声明只读或只写 channel
Go 里单向 channel 不是靠运行时检查，而是靠类型系统在编译期强制约束方向。你不能“把一个普通 channel 变成只读”，只能从双向 chan T 显式转换为 <-chan T（只读）或 chan<- T（只写），且这个转换不可逆。
常见错误现象：cannot assign chan int to chan<- int 或 invalid operation: <-ch (receive from send-only channel)——说明类型不匹配，不是 channel 本身有问题，而是变量声明/传参时方向没对上。
-
func worker(ch <-chan string)：函数只能从ch接收，传入双向chan string没问题，但传入chan<- string就会报错 -
func sender(ch chan<- int)：函数只能往ch发送，传入<-chan int会失败 - 转换必须显式：
ro := <-chan int(c)，不能省略类型；c是chan int才能转，chan<- int无法转成<-chan int
为什么用单向 channel 而不是注释或约定
因为 Go 的 channel 方向是类型的一部分，编译器会严格校验操作合法性。注释或文档说“请勿写入”没用，而类型系统能直接拦住错误代码。
使用场景集中在接口抽象和 goroutine 分工：比如一个生产者函数只应发送，消费者函数只应接收，用单向类型能提前暴露调用方误用（比如在消费者里试图 ch <- x）。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 性能无影响：单向只是编译期类型标签，生成的代码和双向 channel 完全一致
- 兼容性没问题：双向
chan T可以无损转成任一单向类型，但反过来不行 - 别指望运行时检测：如果靠 interface{} 传 channel 再反射判断方向，就彻底绕过了类型安全，也失去了单向的意义
goroutine 启动时怎么安全传递单向 channel
最典型模式是：主 goroutine 创建双向 channel，然后分别以只读/只写形式传给不同子 goroutine，确保它们各司其职。
容易踩的坑是“传错方向”或者“在错误作用域里保留了双向引用”。一旦某个 goroutine 还持有原始双向 channel，单向约束就形同虚设。
- 正确做法：
ch := make(chan int, 1) go producer(ch) // ch 是 chan int go consumer(<-chan int(ch)) // 显式转成只读
- 错误做法：
go consumer(ch)然后在consumer里做ro := <-chan int(ch)—— 这样ch本身还在函数内可见，仍可能被误写 - 别在闭包里捕获双向 channel：比如
go func() { ch <- 1 }()，即使外层参数是<-chan int，闭包也能访问到原始变量
select 里用单向 channel 会有什么限制
只要类型匹配，select 对单向 channel 完全友好。但要注意：只读 channel 只能出现在 <-ch（接收分支），只写 channel 只能出现在 ch <- x（发送分支）。
常见错误现象：invalid operation: ch <- x (send to receive-only channel)，说明你在 <-chan T 上写了发送操作。
-
<-chan int可用于：<-ch、case <-ch:、case v := <-ch: -
chan<- int可用于：ch <- 42、case ch <- 42:，但不能用于接收相关语法 - 别在
select外部对单向 channel 做类型断言或转换，它已经是确定类型，没必要也不安全
单向 channel 的真正价值不在语法糖，而在让接口意图不可篡改。一旦你把 chan<- 交给别人，他就没法偷偷去读；把 <-chan 给出去，你就不用担心他往里塞垃圾数据。这点在大型协作或封装 SDK 时特别关键——不是防君子，是防手滑和重构引入的误用。
