未关闭channel或context缺失会导致goroutine永久阻塞或泄漏；修复需发送方关channel、接收方用for range或select+ctx.Done()，HTTP客户端须设超时，无限循环必须含退出路径。
未关闭的 channel 导致永久阻塞
向无缓冲 channel 发送数据，但没有 goroutine 接收；或从 channel 读取数据，但发送方已退出且未关闭 channel，都会让 goroutine 卡在 chan receive 或 chan send 状态，无法退出。
- 修复方式：确保有且仅有一方负责关闭 channel（通常是发送方），接收方用
for range ch自动退出，或配合select+ctx.Done()双重保障 - 避免对已关闭 channel 再次写入，会 panic；读已关闭 channel 返回零值，需结合 ok 判断
- 无缓冲 channel 尽量只用于同步信号，高并发场景优先选带缓冲 channel 或用 context 替代
context 缺失或未正确响应取消信号
goroutine 启动时未接收 context，或收到 ctx.Done() 后未立即退出，是泄漏高频原因。尤其在定时任务、后台轮询、HTTP 客户端调用中极易出现。
- 所有衍生 goroutine 必须接收并监听
ctx.Done()，并在select中作为首个退出条件 - 不要忽略
default分支导致忙等，也不要漏掉defer cancel()引发的资源残留 - HTTP 客户端必须设置超时：用
http.NewRequestWithContext(ctx, ...)，禁用全局无 timeout 的 client
无限 for-select 循环缺少退出机制
常见于日志采集、指标上报、心跳维持等长周期任务。若 select 中只有 channel 操作而无 ctx.Done() 或超时分支，循环永不终止。
- 强制要求每个
for块内至少有一个可退出路径，例如case - 避免裸写
for {}或for true {}，必须搭配 ticker、timeout 或 done 通道 - 使用
time.AfterFunc或time.NewTicker时，务必defer ticker.Stop()
第三方库启动的 goroutine 未清理
数据库驱动（如 pgx、sqlx）、消息客户端（如 sarama、nats-go）、监控 SDK（如 opentelemetry-go）常在初始化时自动启后台 goroutine。若未调用 Close()、Stop() 或 Shutdown()，它们将持续运行。
- 查阅所用库文档，确认是否有显式关闭方法，并在服务退出前统一调用
- 使用
pprof/goroutine?debug=1对比关停前后堆栈，识别新增的第三方 goroutine - 测试阶段可用
uber-go/goleak在 TestMain 中拦截未回收的 goroutine
HTTP 服务未设超时或连接复用失控
自定义 http.Server 未配置 ReadTimeout、WriteTimeout、IdleTimeout，会导致连接长期空闲不释放；或客户端复用无限制的 transport，堆积大量 idle 连接协程。
- 服务端建议设置：
srv := &http.Server{ReadTimeout: 5 * time.Second, WriteTimeout: 10 * time.Second, IdleTimeout: 30 * time.Second} - 客户端应复用 transport 并限制最大空闲连接：
tr.MaxIdleConns = 100; tr.MaxIdleConnsPerHost = 100 - 避免在 handler 中启动 goroutine 处理请求后不设 context 超时，否则请求结束但 goroutine 仍在跑
锁未释放引发死锁式阻塞
使用 sync.Mutex 或 sync.RWMutex 时，忘记 Unlock()，或在多个锁嵌套顺序不一致，可能造成 goroutine 卡在 semacquire，表现为长时间等待获取锁。
- 一律用
defer mu.Unlock()，避免分支遗漏 - 多锁场景严格按固定顺序加锁（如按变量地址排序），或改用更高级抽象（如
sync.Once、channel 通信） - 启用
-race编译检测竞争，虽不能直接发现锁泄漏，但能暴露加锁逻辑缺陷
defer 延迟函数中启动 goroutine 且未受控
在 defer 中调用 go func() {...}() 是危险模式：外层函数返回后，该 goroutine 才启动，此时其引用的局部变量可能已失效，且缺乏上下文约束，极易失控。
- 禁止在 defer 中启动无生命周期管理的 goroutine
- 如确需异步清理，应传入 context 并在启动时立即监听 Done
- 更安全做法是把清理逻辑封装为同步函数，或由上层统一调度执行
panic 后未 recover 导致 goroutine 非正常终止
goroutine 内发生 panic 且未被 recover，会直接终止，但若它持有 channel、锁、文件句柄等资源，可能留下半开状态，间接导致其他 goroutine 阻塞（如等待其写入 channel）。
- 关键后台 goroutine 应包裹
defer func(){if r := recover(); r != nil { log.Printf("panic recovered: %v", r) }}() - 避免在 goroutine 中抛出未处理 panic，尤其是涉及 I/O、网络、数据库操作时
- 结合
pprof/goroutine查看是否大量 goroutine 处于 running 但实际卡在某行 panic 前代码
