goroutine泄漏比内存泄漏更难发现，因持续创建不退出的goroutine会堆积栈、调度元数据及闭包变量；典型场景包括未关闭channel的for range读取、HTTP handler中无超时控制的goroutine；应通过runtime.NumGoroutine()监控、pprof对比分析阻塞状态，并强制所有异步goroutine绑定context.Context。
goroutine 泄漏比内存泄漏更难发现
Go 程序里内存暴涨，十有八九不是 make([]byte, 1e9) 这种显式分配，而是 goroutine 持续创建却不退出，附带的栈（默认 2KB）、调度元数据、可能持有的闭包变量一起堆积。典型场景是：用 for range 读 channel 却没关 channel，或 HTTP handler 启动 goroutine 但没做超时/取消控制。
- 用
runtime.NumGoroutine()在关键路径打点，上线前加监控告警阈值（比如 >5000） - pprof 查泄漏：启动时访问
/debug/pprof/goroutine?debug=2，对比压测前后堆栈，重点关注阻塞在select{}、chan receive、time.Sleep的 goroutine - 所有异步 goroutine 必须绑定
context.Context，并在入口处用select { case 响应取消
sync.Pool 不是万能缓存，滥用反而增加 GC 压力
sync.Pool 适合复用「临时、短生命周期、构造开销大」的对象，比如 bytes.Buffer、json.Decoder、自定义结构体。但它不解决逃逸问题，也不保证对象一定被复用——GC 会定期清空整个 Pool，且每个 P（逻辑处理器）独占一个子池，跨 P 获取要加锁。
- 不要放含指针字段过多的对象（如大 map），Pool 清空时不会触发其 finalize，可能造成内存滞留
- 必须实现
New字段：否则 Get 返回 nil，容易 panic；且 New 创建的对象不能依赖外部状态（比如从 config 读值） - 避免在热循环里无节制 Put：Put 是无锁的，但大量 Put 会导致 Pool 子池底层数组频繁扩容，间接加剧内存碎片
var bufferPool = sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
// ✅ 正确用法：用完立刻 Put，且确保不会被后续代码继续引用
buf := bufferPool.Get().(*bytes.Buffer)
buf.Reset() // 必须重置，因为 Pool 不保证对象干净
// ... use buf
bufferPool.Put(buf)
channel 缓冲区大小不是越大越好，要匹配消费速率
无缓冲 channel（make(chan int)）要求发送和接收严格同步，适合信号通知；带缓冲 channel（make(chan int, N)）本质是环形队列，底层数组会逃逸到堆上。如果 N 设得远大于实际峰值积压量，就白白占用内存，还可能掩盖下游处理慢的问题。
- 用 pprof heap 查看
runtime.chansend和runtime.chanrecv占用，确认是否 channel 底层数组成了大头 - 生产环境建议设为「平均单次批量处理量 × 2～3」，而非拍脑袋填 1000 或 65536
- 若消费者长期跟不上，优先优化消费逻辑或加限流（如
semaphore），而不是把 buffer 拉到 10w
map 并发读写 panic 时，sync.RWMutex 不是唯一解
直接对全局 map 做并发读写会触发 fatal error: concurrent map read and map write。虽然加 sync.RWMutex 能解决问题，但读多写少时，锁竞争仍明显。Go 1.9+ 提供了 sync.Map，它用空间换时间：读操作几乎无锁，写操作分片加锁，但代价是不支持遍历、不保持插入顺序、值类型必须是 interface{}
立即学习“go语言免费学习笔记（深入）”；
-
sync.Map适合「键固定、读远多于写」场景（如配置缓存、连接池 registry）；频繁增删改查的业务 map 仍推荐普通 map + RWMutex - 别用
sync.Map.LoadOrStore替代简单判断，它内部有原子操作开销，纯读场景用Load更轻量 - 如果 map 键是字符串且长度可控，考虑用
unsafe.String+map[uintptr]Value手动哈希（高级技巧，需谨慎）
go tool pprof -http=:8080 ./binary http://localhost:6060/debug/pprof/heap，盯着 top3 的 alloc_space，比调一百次 GC 参数更管用。 
