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 且关闭时机不明确时。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 遵循“谁创建，谁关闭”原则；避免跨 goroutine 传递关闭责任
- 用
select+default避免盲发：select { case ch <- v: // 成功 default: // ch 可能已关，或缓冲满，按需处理 } - 若必须由接收方决定关闭，改用
sync.Once包裹close(ch)，并配合sync.WaitGroup确保所有发送者退出后再关闭
context.WithTimeout 在 HTTP client 与数据库查询中的误用点
context.WithTimeout 创建的子 context，其超时是相对于调用时刻的绝对截止时间。在长连接池（如 http.Client 或 database/sql.DB）中，它不能自动中断底层 socket 读写——仅影响上层函数是否提前返回错误。
立即学习“go语言免费学习笔记（深入）”；
-
http.Client.Timeout是连接+请求+响应全过程的总时限；而ctx传给Do()只控制该次调用是否被取消，不终止正在进行的 TLS 握手或 TCP 重传 - PostgreSQL 驱动（
lib/pq）支持context，但 MySQL 驱动（go-sql-driver/mysql）直到 v1.7 才完整支持 cancel；旧版本中ctx超时只会中断 query 构建阶段，实际 SQL 仍可能在服务端执行 - 避免在循环中反复调用
WithTimeout创建新 context，应复用父 context 并用WithDeadline精确控制每个操作的截止点
真正难的不是记住这些原语怎么写，而是判断某个操作到底该用 channel 还是 mutex，该用 context.WithCancel 还是直接设固定超时，以及——在压测时发现 goroutine 数翻倍，你得立刻想到去查 /debug/pprof/goroutine 而不是先改代码。
