goroutine 和 channel 是 Go 并发的唯二基石，其他并发控制工具均围绕它们补足短板；新手需先写出可运行、不 panic、结果可预期的最小并发程序。
goroutine 和 channel 是 Go 并发的唯二基石，其他所有并发控制（sync.WaitGroup、sync.Mutex、select）都是围绕它们补足短板的。别从“理论模型”开始，直接动手写能跑通、不 panic、结果可预期的最小并发程序——这才是真正入门。
怎么让 goroutine 不一启动就消失？
新手最常遇到的现象：go fmt.Println("hello") 运行后什么也不输出，程序秒退。这是因为主 goroutine（即 main 函数）执行完就退出了，而新启的 goroutine 还没来得及调度或打印。
- 临时调试：用
fmt.Scanln(&input)阻塞主 goroutine，等你按回车才退出（仅限本地测试） - 生产级做法：用
sync.WaitGroup精确等待——先wg.Add(1)，goroutine 结束前调wg.Done()，主函数末尾wg.Wait() - 千万别用
time.Sleep“凑时间”：它不可靠，CPU 忙闲、GC 触发都会影响实际等待时长
channel 发送/接收卡死？先看是不是无缓冲 + 单向操作
写 ch := make(chan int); ch 然后就卡住？这是无缓冲 channel 的典型行为：发送操作会阻塞，直到有另一个 goroutine 在同一 channel 上执行接收 。它本质是同步点，不是“消息队列”。
- 要异步发送（不阻塞），必须用带缓冲的 channel：
ch := make(chan int, 10)，缓冲满才会阻塞 - 接收端务必在另一个 goroutine 里，否则永远等不到——
go func() { 是常见模式 - 关闭 channel 后再接收会得到零值（如
0forint），但不会 panic；重复关闭会 panic，所以只由 sender 关闭
多个 goroutine 争抢一个变量？别急着加锁，先问能不能用 channel 拆开
比如累加计数器，看到 count++ 被多个 goroutine 并发调用，第一反应不是上 sync.Mutex，而是想：这个变量是否真的需要被所有 goroutine 共享？
立即学习“go语言免费学习笔记（深入）”；
- 如果只是收集结果（如 5 个 worker 各算一部分再汇总），用 channel 把结果“推出来”，主 goroutine 统一收——完全避免共享
- 如果真要共享状态（如全局配置热更新），再用
sync.RWMutex（读多写少时比普通Mutex更高效） - 记住：
sync.Mutex只保护临界区，不解决逻辑竞态。比如“检查再设置”这种操作，即使加锁也需用sync.Once或 CAS（atomic包）
worker 模式怎么写才不漏任务、不 panic？
典型场景：一批 job 分发给固定数量的 worker 并发处理。容易出错的是 channel 关闭时机和接收循环写法。
- 必须由 sender（通常是 main）负责
close(jobs)，且要在所有 job 发送完毕后——不能边发边关 - worker 用
for j := range jobs安全遍历，channel 关闭后自动退出循环，无需额外判断 - results channel 如果不带缓冲，又没及时接收，worker 会卡在
results ；要么加缓冲，要么确保主 goroutine 在 worker 运行时持续
jobs := make(chan int, 5) results := make(chan int, 5) // 缓冲防阻塞// 启动 worker for w := 1; w <= 3; w++ { go func(id int) { for j := range jobs { results <- j * j // 处理并返回 } }(w) }
// 发送任务 for j := 1; j <= 5; j++ { jobs <- j } close(jobs) // 关键：发完再关
// 收结果（顺序不保证） for i := 0; i < 5; i++ { fmt.Println(<-results) }
真正难的从来不是语法，而是判断“这里该不该并发”“数据流该走 channel 还是锁”“谁负责关闭 channel”。这些没法靠背文档解决，只能在一个个真实任务里反复试错、观察 goroutine profile、看 go tool trace 输出——入门之后，下一步就是让并发可观察、可验证。
