close()只能由发送方调用，否则panic；关闭后读取返回零值且ok为false；重复close会panic；len/cap与关闭无关，判断是否关闭只能用<-ch, ok。
close() 只能由发送方调用，否则 panic
Go 的 close() 是单向操作：它只告诉接收方“数据发完了”，不涉及任何同步或等待。如果接收方误调 close()，运行时会直接 panic：panic: close of receive-only channel。编译器通常能捕获这种错误（比如 chan<- int 类型无法传给 close()），但若通过 interface{} 或反射绕过类型检查，就容易踩坑。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 只在明确拥有发送权限的 goroutine 中调用
close()—— 通常是启动该 channel 的那一方 - 避免把 channel 当成“可读可写句柄”反复传递；用
<-chan T向下游传递只读视图，用chan<- T向上游暴露只写接口 - 如果多个 goroutine 共同向一个 channel 发送，必须用 sync.WaitGroup 或其他机制协调，确保仅有一个 goroutine 最终调用
close()
从已关闭的 channel 读取不会阻塞，但会持续返回零值
这是最常被误解的一点：关闭 channel 后，<-ch 不会 panic，也不会阻塞，而是立刻返回 T 的零值（如 0、""、nil）。这本身不是 bug，但容易掩盖逻辑错误 —— 比如你本意是等数据，结果读到一堆 0 却没意识到 channel 已关。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远用带 ok 的语法判断是否真的有数据：
v, ok := <-ch；当ok == false时，说明 channel 已关闭且无剩余数据 - 不要依赖“读到零值”来判断结束；零值可能是合法业务数据（比如计数器发了个 0）
- for-range 隐式处理了 ok 判断，所以
for v := range ch是安全的；但它无法区分“channel 关闭”和“发送方还没关但暂时没发”
重复 close() 会 panic：close of closed channel
Go 明确禁止对已关闭的 channel 再次调用 close()，运行时报错：panic: close of closed channel。不像某些语言的 close() 是幂等的，Go 的 close() 是严格的一次性操作。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要在 defer 中无条件
close(ch)，除非你能 100% 确保该函数是唯一发送方且一定会执行到 defer - 如果发送逻辑有分支（比如出错提前 return），考虑用标志位 + sync.Once 包裹
close()，或者把 close 放在统一出口处 - 测试时注意并发场景：两个 goroutine 同时判断“该不该关”，然后都去 close —— 这需要加锁或用
sync.Once
channel 关闭后，len() 和 cap() 仍可调用，但无实际意义
len(ch) 返回缓冲区中尚未被读取的元素个数，cap(ch) 返回缓冲区容量。它们和 channel 是否关闭完全无关。关闭只是设置一个内部标志位，不影响缓冲区状态。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别用
len(ch) == 0 && cap(ch) == 0来判断 channel 是否“空且已关”——这是错的；关闭后 len 可能还是非零（还有待读数据） - 想确认是否还有数据可读？只能靠
<-ch+ ok 判断，或者用select配合 default 分支做非阻塞探测 - 关闭后的 channel 依然可以被多次接收（只要还有缓冲数据），直到缓冲耗尽才开始返回零值+false
channel 关闭的本质不是“销毁资源”，而是“发送 EOF 信号”。真正容易被忽略的是：这个信号没有时间戳、不可撤销、不可重放，而且一旦发出，所有后续接收行为都进入确定但易误判的状态。别把它当成同步原语用，也别指望靠它触发下游清理 —— 那些得靠额外的 done channel 或 context.Context。
