goroutine 不是线程，channel 不是共享内存；主函数不等待 goroutine，需用 sync.WaitGroup 显式同步；无缓冲 channel 要求收发同时就绪，否则 deadlock；带缓冲 channel 仅缓解阻塞，不保证并发安全。
goroutine 不是线程，channel 不是共享内存——用错模型是并发 bug 的主要来源。
goroutine 启动后不等待就退出主函数？
Go 程序默认只等 main 函数返回，不会自动等待未结束的 goroutine。常见现象是：启动了 go doWork()，但程序立刻退出，doWork 根本没执行完。
- 用
sync.WaitGroup显式等待：在 goroutine 启动前调用wg.Add(1)，在 goroutine 结束时调用wg.Done()，主函数末尾阻塞wg.Wait() - 避免用
time.Sleep模拟等待——它不可靠、难维护、掩盖逻辑缺陷 - 注意
WaitGroup必须在 goroutine 外部调用Add，不能在 goroutine 内部调用（否则可能漏加或 panic）
channel 发送/接收时卡死（deadlock）？
最典型的错误是：向无缓冲 channel 发送数据，但没有 goroutine 同时准备接收；或从空 channel 接收，但没人发送。运行时报 fatal error: all goroutines are asleep - deadlock!。
- 无缓冲 channel（
make(chan int)）要求发送和接收必须“同时就绪”，适合同步协作场景 - 带缓冲 channel（
make(chan int, 10)）允许先发后收，缓冲区满才阻塞；但缓冲区大小不是并发数，别误以为设成 10 就能安全启 10 个 goroutine - 用
select+default做非阻塞操作，或加超时：select { case v :=
关闭 channel 后继续发送会 panic
对已关闭的 channel 执行 ch 会立即 panic：<code>send on closed channel。但接收仍可进行——会得到零值并返回 ok == false。
立即学习“go语言免费学习笔记（深入）”；
- 只有 sender（即负责写入的一方）应关闭 channel；receiver 关闭是错的，且 Go 不允许
- 多个 sender 时，谁关？通常由任务协调者（如主 goroutine 或专用控制 goroutine）统一关闭，避免重复 close 导致 panic
- 用
for range ch安全遍历 channel，它会在 channel 关闭且数据读尽后自动退出循环
goroutine 泄漏：忘了取走 channel 里的数据
向带缓冲 channel 发送数据后，若无人接收，缓冲区会一直占着内存；若 sender 是 goroutine，它可能永远阻塞在 ch ，导致 goroutine 无法退出——这就是泄漏。
- 检查所有
ch 调用点，确认必有对应接收逻辑（哪怕是在另一个 goroutine 中） - 避免在循环中无条件发数据却不配对消费，尤其当 channel 是闭包变量或跨 goroutine 共享时
- 用
runtime.NumGoroutine()在测试中观察数量是否随请求稳定，而非持续增长
真正难的不是语法，而是判断「谁负责关闭 channel」「谁该等待」「数据生命周期是否匹配 goroutine 生命周期」——这些设计决策一旦定错，调试成本远高于写代码本身。
