单向通道是编译期类型系统对数据流向的强制声明，不改变底层行为，仅在编码时拦截错误；不能用 make 直接创建单向通道变量，需通过双向通道转换。
单向通道不是运行时的“锁”，而是编译期类型系统对数据流向的强制声明——它不改变底层通道行为，只让错误在写代码时就被拦住。
怎么声明和赋值单向通道变量
不能用 make 直接创建真正可用的单向通道变量，比如 make( 或 <code>make(chan 虽然语法合法，但生成的通道永远空或永远满，毫无实用价值。
- 正确起点永远是双向通道：
c := make(chan int, 10) - 单向视图必须从它派生：
ro := （显式转换更清晰）或 <code>wo := chan - 声明变量时可直接写类型，但右值必须是双向通道或其转换结果：
var in ✅，<code>var in ❌（无发送方，死锁）
函数参数中传单向通道为什么能隐式转换
Go 允许将 chan T 隐式转为 或 <code>chan，这是类型兼容规则，不是自动“降级”。反过来则不行。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 调用
func worker(in 时传 <code>c（chan string）✅，编译器自动适配 - 但若函数定义为
func legacy(ch chan string)，传入ro（）会报错：<code>cannot use ro (type - 隐式转换只发生在函数调用、赋值等上下文中；在结构体字段或接口实现里仍需严格匹配
select 里用单向通道要注意什么
select 语句本身不限制通道方向，但它要求每个分支的操作必须与通道类型兼容。
只能用于 <code>（接收分支），写成 <code>ch 会编译失败：<code>invalid operation: cannot send to receive-only channelchan 只能用于 <code>ch （发送分支），写成 <code> 同样报错：<code>invalid operation: receive from send-only type- 如果通道变量是双向的，
select里可以混用收发；一旦转成单向，对应操作就彻底不可见了
关闭单向通道的权限边界在哪
close() 的调用权限只看底层通道是否支持发送，跟变量声明方向无关——但编译器会检查你“有没有这个权利”。
- 只有类型含
chan（即能发送）的变量才允许 <code>close(ch)，哪怕它是从chan int转来的 类型变量调用 <code>close()会直接编译失败：invalid operation: close(c) (channel is receive-only)- 关键点：关闭动作本身由发送端负责，且只能关一次；接收端即使持有单向视图，也不能绕过类型系统去关
最容易被忽略的是：单向通道的约束完全依赖于你是否“只保留单向引用”。只要某个 goroutine 还持有原始双向通道变量，所有单向限制就形同虚设——类型安全只作用于变量名，不作用于底层内存。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
