goroutine泄漏表现为内存持续增长、numgoroutine()值只增不减；常见于未关闭channel接收、select阻塞、未调用cancel()；可用pprof查看堆栈，-gcflags=”-m”分析逃逸，defer中检查ctx.err()清理。
goroutine 泄漏的典型表现与快速定位方法
goroutine 泄漏不是报错，而是程序内存持续增长、runtime.NumGoroutine() 返回值只增不减。常见于未关闭的 channel 接收、阻塞在 select 等待永远不发生的 case、或忘记调用 cancel() 导致 context 无法退出。
- 用
pprof查看 goroutine 堆栈：curl http://localhost:6060/debug/pprof/goroutine?debug=2 - 启动时加
-gcflags="-m"观察逃逸分析，确认是否意外捕获了大对象导致 goroutine 持有引用 - 对所有带超时/取消逻辑的 goroutine，强制在 defer 中检查
ctx.Err() == context.Canceled并做清理
sync.Mutex 和 sync.RWMutex 的真实适用边界
sync.Mutex 不是万能锁，也不是性能瓶颈本身；它的代价在于竞争时的调度开销和缓存行争用。读多写少场景下，sync.RWMutex 只有在真正存在并发读（且读操作耗时明显）时才值得引入——否则它比 sync.Mutex 更重，因为内部维护了额外的状态字段和 goroutine 队列。
- 若读操作只是简单取一个
int或指针，直接用atomic.LoadInt64比任何 mutex 都快 -
RWMutex的写锁会阻塞新读锁获取，但已持有的读锁不会被中断；这意味着写操作可能长时间等待，尤其当读 goroutine 频繁创建时 - 不要嵌套使用
RWMutex：先RUnlock()再Lock()，否则死锁
channel 关闭后继续发送 panic 的规避策略
向已关闭的 channel 发送数据会触发 panic: send on closed channel，但接收是安全的（返回零值 + false）。问题常出现在多个 goroutine 共享同一 channel 且关闭时机不明确时。
