Go并发需谨慎控制goroutine数量，避免盲目启动；须用WaitGroup、带缓冲channel或errgroup.Group节流；HTTP请求天然限流可单启goroutine，批量处理需worker pool；time.AfterFunc等需context控制生命周期；channel操作不当易导致阻塞或panic。
Go 里并发不是靠加 goroutine 就完事
盲目在循环里起 go func() 是最常见错误。goroutine 轻量，但不免费：调度开销、内存占用、竞态风险都会随数量线性增长。真实系统里，必须配合控制手段——要么用 sync.WaitGroup 等待结果，要么用带缓冲的 chan 做节流，要么直接上 errgroup.Group。
- HTTP 服务中每个请求启一个 goroutine 是安全的，因为请求天然限流（连接数、超时、反向代理限制）
- 批量处理 10 万条日志？不能直接
for _, log := range logs { go process(log) }，得用 worker pool 模式 -
time.AfterFunc或time.Tick启的 goroutine 容易泄漏，务必配context.WithCancel控制生命周期
channel 用法错一半，程序就卡死或 panic
channel 不是万能队列，它的阻塞行为直接决定 goroutine 是否挂住。写入已关闭的 channel 会 panic；从已关闭且无数据的 channel 读，得到零值；无缓冲 channel 写之前没人读，就永远阻塞。
- 发送前先检查
select { case ch 避免阻塞 - 关闭 channel 的责任必须明确——通常只由发送方关闭，接收方不应 close
- 用
for range ch读 channel 时，如果 sender 永不 close，循环永不退出 - 不要用 channel 传大结构体，避免拷贝；优先传指针或
sync.Pool复用对象
func worker(id int, jobs <-chan int, results chan<- int, done <-chan struct{}) {
for {
select {
case job, ok := <-jobs:
if !ok {
return
}
results <- job * 2
case <-done:
return
}
}
}context.Context 不只是传取消信号
它还承载超时、截止时间、值传递、取消链路。漏传 ctx 到下游调用（比如 http.Client.Do(ctx, req)、db.QueryContext(ctx, ...)），整个链路就失去控制能力。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- HTTP handler 入口的
ctx来自r.Context()，别自己 new - 用
context.WithTimeout时，记得 defercancel()，否则可能泄露 timer -
context.WithValue只适合传请求范围的元数据（如用户 ID、trace ID），禁止传业务参数或函数对象 - 数据库连接池、gRPC client、Redis client 都要求传 ctx，否则超时和取消无效
sync.Mutex 和 atomic.Value 不是二选一
简单字段读写用 atomic.LoadInt64 / atomic.StoreUint64 更快；但涉及多个字段关联更新（比如状态 + 时间戳）、或需要条件等待（sync.Cond），就必须用 sync.Mutex。混用两者极易出错。
立即学习“go语言免费学习笔记（深入）”；
-
atomic.Value只能存指针或接口类型，且每次Store都是全量替换，不适合高频小字段更新 - 用
sync.RWMutex时，注意RUnlock必须和Rlock成对，漏掉会导致后续所有写锁永久阻塞 - struct 字段加
mu sync.RWMutex后，别忘了所有访问都得显式加锁——编译器不会报错，但数据竞争检测器（go run -race）会抓到
真正难的不是写并发代码，而是判断某段逻辑是否必须并发、并发粒度该划多细、失败后怎么回滚或重试。这些没法靠语法糖解决，得结合监控指标（goroutine 数、channel 阻塞数、GC pause）和压测反复验证。
