Go中单向channel通过类型系统强制约束：chan
怎么声明只读或只写的 channel 类型
Go 里单向 channel 不是靠运行时约束，而是靠类型系统强制——你声明成 chan 就只能发，<code> 就只能收。编译器会直接报错，不是靠文档或约定。
关键点：单向类型只能由双向 channel 转换而来，不能直接 make 出来。
-
make(chan int)返回的是双向chan int，这是唯一能用make创建的 channel 类型 - 转成只写：
c := make(chan int); sendOnly := (chan - 转成只读：
c := make(chan int); recvOnly := ( - 函数参数中直接写
ch 或 <code>ch chan，调用时传双向 channel 自动隐式转换
为什么要把 channel 声明成单向的
核心作用就一个：让接口更清晰、错误更早暴露。比如一个生产者函数只往 channel 发数据，那它就不该有“从里面读”的能力——哪怕只是误操作，编译器也能拦住。
常见场景：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- worker goroutine 只消费：
func worker(ch —— 这里连 <code>ch 都会编译失败 - 生成器函数只产出：
func gen() chan —— 返回值不能被接收，避免下游误用 - 管道组合时避免反向数据流：多个 stage 串联，每个 stage 的输入/输出类型明确，不会出现意外的
或 <code> 操作
容易踩的坑：类型转换和 nil channel 行为
单向 channel 的零值仍是 nil，和双向一样。但因为类型不同，nil 的单向 channel 依然会阻塞或 panic（取决于操作）。
var ch 是 <code>nil，执行编译不通过（类型不匹配），但 <code>ch 会 panic：send on nil channelvar ch chan 是 <code>nil，执行ch 同样 panic；但 <code> 编译失败（不能从只写 channel 接收）- 别试图对单向 channel 做类型断言回双向：
(chan int)(ch)会编译失败——Go 不允许反向转换 - 函数返回单向 channel 时，如果内部用
make(chan int)创建，必须显式转换再 return，否则类型不匹配
实际传参时的兼容性细节
Go 允许把双向 channel 当作单向传给函数，但反过来绝对不行。这个规则决定了设计 API 时的自由度。
- 函数签名写
func f(ch ，你可以传 <code>make(chan int)、、甚至 <code>chan（虽然语义奇怪，但类型上合法） - 但如果函数要返回单向 channel，比如
func newSender() chan，内部必须做一次转换：<code>c := make(chan string); return (chan - 注意 struct 字段不能是单向 channel 类型（Go 1.22 仍不支持），会报错：invalid recursive type —— 所以别在 struct 里存
chan
单向 channel 的约束力全靠类型系统，没 runtime 开销，但一旦写错类型，编译器报错信息可能有点绕，比如 “cannot use … as … in argument to …”——这时候先盯住函数签名里的 和 <code>chan 方向，再看实参类型是否匹配。
