单向channel是Go类型系统中带运行时语义的关键特性：编译期强制方向检查，
传入 chan int 却想只读？编译直接报错
Go 编译器会严格检查 channel 的方向性。如果你函数签名写的是 func f(c chan int)，调用方传 chan 或 <code> 都会失败——双向 channel 和单向 channel 类型不兼容，哪怕底层结构一样。
真正能接受只读 channel 的参数类型必须显式声明为 ；同理，只写必须用 <code>chan。这是类型系统强制的契约，不是可选提示。
- 错误写法：
func process(c chan int) { → 无法接收 <code> 实参 - 正确写法：
func process(c → 只读安全，且能接收 <code>chan int和 - 注意：
chan int可以隐式转换为或 <code>chan，但反过来不行
chan 参数不能关闭？运行时报 panic
函数如果只声明了 chan 参数，说明它只负责发送，不持有接收端权限。此时若在函数内调用 <code>close(c)，Go 编译器不会拦（因为语法合法），但运行时只要该 channel 真实是单向的（比如由 make(chan int) 创建后转成 chan 传入），<code>close 就会 panic："panic: close of send-only channel"。
- 根本原因：单向 channel 的方向信息在运行时仍被保留，
close检查实际类型，不看变量声明 - 安全做法：只对双向 channel 调用
close；若必须由发送方关闭，请用chan int类型传参，并确保调用方清楚责任 - 常见误操作：把
make(chan int, 10)转成chan 后传给一个“以为自己能关”的函数
为什么用 而不是 <code>interface{} 做管道输入？
用 interface{} 接收 channel 看似灵活，实则放弃所有类型和方向检查，等于把问题推给运行时或调用者。而 明确表达“我只从这个管道读 <code>string”，编译器能帮你挡住：chan int、chan、<code> 这三类错误。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 性能无差异：单向 channel 是编译期类型约束，无运行时代价
- 可读性提升：看到参数类型就知道数据流向和内容类型，不用翻文档或猜逻辑
- 配合 select 更安全：在
case 中，<code>c是才能编译通过，避免误写成 <code>case c
goroutine 泄漏常藏在 参数里
很多工具函数用 做 done 信号，比如 <code>func watch(done 。但如果调用方传入的是未关闭的 <code>chan bool（或忘了 close），这个 goroutine 就永远卡在 select 上，无法退出。
- 关键点：单向 channel 不改变底层 channel 的生命周期，
仍需被关闭才能让接收方退出 - 建议：函数内部加超时兜底，或文档明确要求调用方保证
done必关；不要假设“传进来的 done 总是有效的” - 调试线索：pprof 查 goroutine 数量持续上涨，堆栈停在
runtime.gopark+ 你的 channel 读操作
事情说清了就结束。单向 channel 不是语法糖，它是 Go 类型系统里少数几个带运行时语义的类型——方向错了，编译过不了；关错了，运行就崩；漏关了，goroutine 就飘着。
