go语言生产级并发需精准控制goroutine生命周期、channel收发配对与关闭、context显式传递及waitgroup正确计数，否则易触发死锁或协程丢失。
Go 语言不是“学完语法就能写生产代码”的语言。真正卡住多数人的，是 goroutine 生命周期失控、channel 死锁、context 传递断裂、sync.WaitGroup 使用时机错乱——这些都不是语法错误，而是对运行时模型理解偏差导致的隐性故障。
goroutine 启动后就“消失”了？必须显式等待或同步
新手常以为 go 启动协程后，主函数会自动等它结束。实际不会：主 goroutine 退出，整个程序立即终止，子 goroutine 被强制杀死，且无提示。
- 常见错误现象：
go fmt.Println("hello")后直接return，控制台可能不输出任何内容 - 正确做法：用
sync.WaitGroup计数，或用channel阻塞接收（如） - 注意
WaitGroup.Add()必须在go语句前调用，不能在 goroutine 内部调用（竞态风险） - 若 goroutine 可能 panic，需在内部加
defer recover()，否则会终止整个程序
channel 发送/接收不配对？死锁是默认行为
Go 的 channel 是同步原语，不是消息队列。无缓冲 channel 要求发送和接收**同时就绪**，否则阻塞；一旦所有 goroutine 都卡在 channel 操作上，就会触发 runtime panic: fatal error: all goroutines are asleep - deadlock!
- 典型场景：只发不收（如漏写
）、只收不发（如 <code>ch := make(chan int); ）、在同一个 goroutine 里对无缓冲 channel 先发后收 - 带缓冲 channel（
make(chan int, 1)）可缓解，但只是延迟死锁，不是根治——缓冲区满后仍会阻塞 - 安全模式：总是配合
select+default或timeout，例如select { case ch - 关闭 channel 前确认：只有 sender 应该
close(ch)；receiver 收到零值后应停止读取，否则会持续收到零值
context.WithCancel 不传播？父子关系靠显式传参建立
context 不是全局变量，也不会自动跨 goroutine 传递。它的取消信号依赖「父子链」，而这条链必须由开发者手动构建。
- 错误写法：
ctx, cancel := context.WithCancel(context.Background())，然后在另一个 goroutine 里直接用context.Background()——两者完全无关 - 正确方式：把
ctx作为参数传给每个需要响应取消的函数，包括所有go启动的函数 - HTTP handler 中，
r.Context()是从请求生命周期派生的，必须向下传递，不能自己新建context.Background() - 注意
cancel()只影响当前 context 及其子孙，不影响父 context；多次调用cancel()是安全的，但无意义
sync.Mutex 保护的是数据，不是代码段
初学者容易把 sync.Mutex 当作“临界区锁”，以为加了 mu.Lock() 就万事大吉。其实它只保证同一时间只有一个 goroutine 进入被保护的代码块，**但不保证被保护的数据没被其他路径修改**。
- 典型漏洞：结构体字段被多个 mutex 分别保护，或某个字段根本没被锁住
- 更隐蔽的问题：方法接收者是值类型（
func (s S) Get() {}），锁在副本上，原结构体未受保护 - 推荐做法：让 mutex 成为结构体字段，且所有访问该结构体状态的方法都使用指针接收者（
func (s *S) Set() {}） - 避免嵌套锁：A 锁内调 B 锁，B 锁内又调 A 锁 → 死锁；优先用
sync.RWMutex区分读写场景
真正难的从来不是写 go，而是判断“此刻该不该启动 goroutine”、以及“它该听谁的指令退出”。这些决策背后是对 Go 运行时调度模型和内存模型的持续校准——没有一次调试能教会你全部，但每一次 panic: send on closed channel 都在帮你重连这个认知。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
