Go并发控制靠channel、sync.Mutex、sync.WaitGroup和context.Context四类原语轻量约束；channel用于协作/流控，Mutex仅保护共享变量读写；Pool需重置状态且易致内存泄漏，高频小结构体宜直接分配，大buffer用bytes.Buffer.Reset()更可控；稳定性取决于资源释放时机、清理责任及超时取消是否穿透到底层I/O。
Go 的并发控制不是靠“设计大架构”实现的，而是靠组合 channel、sync.Mutex、sync.WaitGroup 和 context.Context 这四类原语，在关键路径上做轻量、明确的约束。
什么时候该用 channel 而不是 sync.Mutex
核心判断标准：是否涉及「协作」或「流控」。仅保护共享变量读写，用 sync.Mutex 更直接；若需协调 goroutine 启停、传递信号、限速、背压（如生产者-消费者），必须用 channel。
-
channel天然带同步语义，ch 会阻塞直到有接收方，这是 <code>Mutex永远做不到的 - 关闭
channel是向所有接收方广播“结束”的唯一安全方式，别用bool变量模拟 - 避免在循环里反复创建无缓冲
channel——这会频繁触发调度器，性能比Mutex差一个数量级 - 高频小数据通信（如每毫秒一次状态更新），优先考虑
atomic.Value+sync.RWMutex，而非chan struct{}
context.WithTimeout 必须和 select 配合使用才生效
context.WithTimeout 本身不中断任何 goroutine，它只让 ctx.Done() 返回的 channel 在超时后可被接收。不写 select，超时就完全没意义。
- 常见错误：启动 goroutine 后丢弃
ctx，或只在入口处检查ctx.Err()但未在 I/O 或循环中持续监听 - HTTP handler 中，
ctx来自 request，应透传给下游调用（如数据库查询、RPC），且每个阻塞操作都应参与select - 不要用
time.After替代ctx.Done()——前者无法被取消，会泄漏 timer - 子 context（如
WithCancel）的 cancel 函数必须显式调用，且只能调用一次；重复调用 panic，漏调则资源泄漏
高并发下 sync.WaitGroup 的典型误用场景
WaitGroup 本质是计数器，不是 goroutine 生命周期管理器。它只保证“所有 Add 的数量都被 Done”，不保证 goroutine 已结束或未 panic。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 绝不能在 goroutine 内部调用
wg.Add(1)——竞态风险极高，应全部在启动前调用 - 如果 goroutine 可能 panic，
defer wg.Done()必须放在函数最顶部，否则 panic 后Done不执行，Wait永远阻塞 - 大量短生命周期 goroutine（如每请求启 100 个）时，
WaitGroup的原子操作开销明显，此时改用errgroup.Group更简洁且自带错误传播 -
WaitGroup无法等待“动态数量”的 goroutine（比如根据配置启 N 个 worker），这种场景必须用channel+ 计数器或errgroup
为什么 sync.Pool 在 HTTP 服务中常被误用
sync.Pool 适合复用**大对象、构造开销高、生命周期可控**的实例（如 bytes.Buffer、json.Decoder）。但在典型 HTTP server 中，它往往收益甚微甚至有害。
- Go 1.22+ 默认启用
GC并发标记，小对象分配已极快，Pool的收益主要在 >1KB 对象上 - HTTP handler 中获取
Pool.Get()后，若忘记Put()或Put了错误类型（如把 *bytes.Buffer 放进 []byte Pool），会引发静默内存增长 -
Pool中的对象可能被 GC 清理，所以每次Get()后必须重置状态（如b.Reset()），不能假设内容为空 - 更推荐做法：对高频小结构体（如 request context 数据），直接分配；对大 buffer，用
bytes.Buffer并在 handler 结束时Reset()，比Pool更可控
真正决定并发系统稳定性的，从来不是用了多少并发原语，而是谁在什么时机释放资源、谁负责清理、超时和取消是否穿透到最底层 I/O。这些细节藏在 select 分支里、defer 语句中、以及每个 Close() 调用之后。
