无缓冲 channel 发送就卡住是因为其容量为0、底层dataqsiz为0且buf为nil，不缓存数据，发送必须与另一goroutine的接收实时“手递手”同步完成，否则永久阻塞。
无缓冲 channel 发送就卡住，为什么？
因为无缓冲 channel 的 make(chan int) 不带容量，底层 dataqsiz 为 0、buf 为 nil，它不存数据，只做“手递手”交接。发送方必须等到接收方在另一端执行 ，否则 <code>ch 立即阻塞。
常见错误现象：
- 单个 goroutine 向无缓冲 channel 发送后没其他 goroutine 接收 → 触发
fatal error: all goroutines are asleep - deadlock! - 误以为 “写完就继续”，结果主 goroutine 挂死，程序退出
使用场景有限但关键：
- 同步信号：比如用
done := make(chan struct{})通知任务结束 - 协程启动屏障：启动 goroutine 后立刻
，确保它已初始化完毕
缓冲 channel 的“非阻塞”是假象？
不是假象，但有前提：ch := make(chan int, 3) 的发送操作仅在 qcount 时才不阻塞。一旦缓冲区填满（<code>qcount == 3），ch 仍会阻塞——它只是把阻塞时机从“必须配对”推迟到了“缓冲区满”。
容易踩的坑：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 设了缓冲却仍死锁：比如生产者发满 5 条，消费者只读 3 条就退出，剩下 2 条卡在 buffer 里，后续发送再阻塞
- 缓冲大小拍脑袋定：设
make(chan int, 1000)看似安全，但若消费者长期不消费，内存持续增长，GC 压力大 - 误读
len(ch)：它返回当前缓冲中元素数（qcount），不是 cap，不能当“是否可写”判断依据
select 里 default 怎么影响 channel 阻塞行为？
select 本身不改变 channel 的阻塞逻辑，但它决定了你“要不要等”。有没有 default 分支，直接切换整个语句的调度模式：
- 无
default：所有case都不可执行时，select阻塞，直到某个 channel 就绪（哪怕等 10 秒） - 有
default：只要所有case当前不可执行（如空的无缓冲 channel、满的缓冲 channel），立刻进default，不等
典型误用：
- 在超时控制里漏写
default，导致select卡死，time.After失效 - 用
default做“快速试探”，却忘了缓冲 channel 可能有残留数据，实际能立刻读到旧值，而非进入 <code>default
关闭 channel 后，缓冲里的数据还能读吗？
能。关闭只影响“后续写入”和“读取状态”，不清理缓冲区。对缓冲 channel 调用 close(ch) 后：
- 继续
ch → panic: send on closed channel - 继续
v, ok := → 若缓冲还有数据，<code>v是下一个值，ok为true；若缓冲已空，v是零值，ok为false
这个细节常被忽略：很多人以为 close() 就等于“清空并终止”，结果在循环读取时少读几条——因为 for range ch 会自动处理关闭逻辑，但手动 不会。
真正容易出问题的地方是：关闭后还依赖缓冲区长度做判断，比如用 len(ch) > 0 认为“还有活干”，其实 channel 已关，后续读可能返回零值而不报错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
