goroutine泄漏典型征兆是内存持续上涨且runtime.numgoroutine()只增不减；定位需用pprof抓取堆栈、godebug=schedtrace=1000观察grs增长，并结合context控制生命周期。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 免费无限量使用 DeepSeek R1 模型☜☜☜
goroutine 泄漏的典型征兆和快速定位方法
Go 程序跑着跑着内存持续上涨、runtime.NumGoroutine() 返回值只增不减，基本就是 goroutine 泄漏了。它不像 panic 那样立刻报错，而是悄悄吃光内存、拖慢调度器。
常见泄漏场景：channel 未关闭导致 range 卡死、select 中缺少 default 或 timeout、HTTP handler 启动 goroutine 但没绑定 request context 生命周期。
- 用
pprof抓取 goroutine stack：curl http://localhost:6060/debug/pprof/goroutine?debug=2，重点看阻塞在chan receive或semacquire的堆栈 - 启动时加
GODEBUG=schedtrace=1000，每秒打印调度器状态，观察GRs（goroutines）列是否单边增长 - 对关键 goroutine 使用
context.WithCancel或context.WithTimeout显式控制生命周期，别依赖“等它自己结束”
sync.WaitGroup 误用导致程序 hang 死的三种写法
WaitGroup 不是万能等待器，它只计数，不保序、不传错、不自动回收。写错一行，main 就卡住不动。
最常踩的坑是 Add 和 Done 不配对，或者在 goroutine 外提前调用了 Wait()。
立即学习“go语言免费学习笔记（深入）”；
-
WaitGroup.Add()必须在go语句前调用，不能放在 goroutine 内部——否则可能还没 Add 就 Wait 了 - 别用
defer wg.Done()在匿名函数里，容易因闭包捕获错误变量导致多次 Done 或漏 Done - 如果 goroutine 可能 panic，记得 recover 后仍要调用
wg.Done()，否则 Wait 永远不返回
select + channel 组合中 timeout 和 cancel 的正确姿势
用 select 等待多个 channel 时，超时和取消不是可选项，是必选项。否则一个没响应的 channel 就让整个逻辑挂起。
别再手写 time.After() 做 timeout——它会持续运行到超时，哪怕你早就退出了 select；也别把 ctx.Done() 和业务 channel 平权放一起，忽略 cancel 优先级。
- 始终优先监听
ctx.Done()，并在 case 中处理ctx.Err()，而不是等 timeout 触发 - 用
time.NewTimer()替代time.After()，用完记得timer.Stop()防止泄露定时器 - 如果 channel 是无缓冲的，且发送方可能不发，务必加 timeout，否则 select 会永久阻塞
并发读写 map panic 的真实触发条件和替代方案
fatal error: concurrent map read and map write 这个 panic 不是“只要两个 goroutine 同时碰 map 就炸”，而是在「至少一个写操作」+「任意读写并发」时才触发。读读并发是安全的，但 Go runtime 不做检测，所以侥幸活下来不代表没问题。
很多人第一反应是加 sync.RWMutex，但它锁粒度太粗，容易成为瓶颈；也有人直接上 sync.Map，结果发现它只适合读多写少、key 类型固定、且不需遍历的场景。
- 如果只是临时缓存、key 数量可控，用
sync.Map没问题；但需要 range、len() 或保证迭代顺序时，必须换回原生 map + 读写锁 - 高频写 + 低频读？考虑分片 map（sharded map），比如按 key hash 分 32 个子 map，各自配一把
sync.RWMutex - 所有 map 访问入口必须统一，别一部分走 mutex 包裹，另一部分直读——这种混合写法 runtime 查不出来，但数据一定乱
goroutine 的边界感比想象中更脆弱：它不自动清理资源，不隐式传递 context，也不校验共享数据访问。写并发代码时，每一行都要问自己——这个变量谁在读、谁在写、谁负责关、谁负责停。
