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：send on closed channel。但接收仍可进行——会得到零值并返回 ok == false。
