应使用 context.Context 控制 goroutine 生命周期，通过 WithCancel、WithTimeout 等派生上下文实现主动取消与超时终止，避免 time.Sleep、轮询 flag 或强杀进程；channel 要遵循发送方关闭、select 阻塞通信、struct{} 传信号等原则。
用 context.Context 控制 goroutine 生命周期，别靠 time.Sleep 或全局 flag
并发代码失控的根源，往往是 goroutine 启动后无法被主动取消或超时终止。硬编码 time.Sleep、轮询 bool 变量、或依赖 os.Exit 强杀，都会导致资源泄漏或状态不一致。
正确做法是把 context.Context 作为第一参数传入所有可取消的并发函数：
func fetchUser(ctx context.Context, id int) (string, error) {
// 使用 ctx.WithTimeout 或 ctx.WithCancel 构建子 ctx
ctx, cancel := context.WithTimeout(ctx, 3*time.Second)
defer cancel()
select {
case <-time.After(2 * time.Second):
return "alice", nil
case <-ctx.Done():
return "", ctx.Err() // 自动返回 context.Canceled 或 context.DeadlineE
xceeded
}}
-
context.WithCancel用于手动触发停止（比如用户点击取消） -
context.WithTimeout/context.WithDeadline适用于网络请求、数据库查询等有明确时限的场景 - 永远不要在 goroutine 内部忽略
ctx.Done()—— 即使你认为“很快就能结束”，也要 select 监听它 - 避免把
context.Background()直接传给长期运行的 goroutine；应由调用方提供带取消能力的上下文
channel 用法：别只当队列，要懂阻塞语义和所有权转移
很多人把 chan 当作 Go 的“消息队列”，但真正优雅的并发依赖的是 channel 的阻塞特性与通信即同步（CSP）本质。错误用法包括：for range 死循环不退出、向已关闭 channel 发送、或多个 goroutine 竞争写同一 channel 而无协调。
关键原则：
- 发送方负责关闭 channel —— 接收方永远不要 close 一个只接收的 channel
- 用
select+default实现非阻塞尝试发送/接收，但要清楚这会跳过逻辑，不是“重试” - 若需多路复用，优先用
select而非多个 goroutine + mutex - 考虑使用
chan struct{}表达信号，而非chan bool（零内存占用，语义清晰）
示例：等待任意一个任务完成，且不泄露 goroutine
func waitForFirst(ctx context.Context, fns ...func(context.Context) error) error {
ch := make(chan error, len(fns))
for _, fn := range fns {
go func(f func(context.Context) error) {
ch <- f(ctx)
}(fn)
}
select {
case err := <-ch:
return err
case <-ctx.Done():
return ctx.Err()
}
}别滥用 sync.WaitGroup，优先用 channel 或 errgroup.Group
sync.WaitGroup 是基础工具，但容易写出“伪并发”：比如在 goroutine 启动前就 wg.Add(1)，却忘了 recover panic 导致 wg.Done() 永远不执行；或误用 wg.Wait() 在循环里阻塞主线程。
更现代、更安全的选择：
- 用
errgroup.Group（来自golang.org/x/sync/errgroup）自动收集错误、共享 context、且无需手动调用Done() - 对简单扇出/扇入场景，用 channel 关闭 +
range天然实现等待，语义更清晰 - 若必须用
WaitGroup，确保Add和Done成对出现在同一 goroutine 中，或用defer wg.Done()锁死调用路径
对比示例：
// ❌ 容易 panic 泄露
var wg sync.WaitGroup
for i := 0; i < 3; i++ {
wg.Add(1)
go func() {
defer wg.Done() // 如果这里 panic，wg.Done 不执行
doWork()
}()
}
wg.Wait()
// ✅ 用 errgroup，自动绑定 ctx，panic 也不漏 Done
g, ctx := errgroup.WithContext(context.Background())
for i := 0; i < 3; i++ {
i := i
g.Go(func() error {
return doWorkWithContext(ctx, i)
})
}
if err := g.Wait(); err != nil {
log.Println("one failed:", err)
}
并发读写 map 和 slice：不是所有“共享变量”都该加锁
新手常犯的错：一看到“多个 goroutine 访问同一个变量”，立刻套上 sync.RWMutex。但 map 和 slice 的并发读写限制有明确边界 —— 它们本身不是线程安全的，但“只读”或“生命周期隔离”的场景根本不需要锁。
真正需要干预的情况：
- map 被多个 goroutine 同时
write（包括delete），或read与write并发 → 必须用sync.Map或显式锁 - slice 被多个 goroutine 同时
append→ 数据竞争，panic 或静默损坏；应预先分配好容量，或改用 channel 传递元素 - 如果只是多个 goroutine 读同一个 map/slice，且初始化完成后不再修改 → 安全，无需锁
- 高频小对象读写？
sync.Map并不总是更快 —— 它适合读多写少、key 分布广的场景；简单场景用map + RWMutex更直观可控
典型反模式：
// ❌ 并发 append，data race！
var data []int
for i := 0; i < 10; i++ {
go func() {
data = append(data, i) // 危险！
}()
}
// ✅ 改为 channel 收集结果
ch := make(chan int, 10)
for i := 0; i < 10; i++ {
go func(v int) { ch <- v }(i)
}
go func() {
for i := 0; i < 10; i++ {
data = append(data, <-ch)
}
}()
并发的优雅不在语法多炫，而在每个 goroutine 是否知道自己何时开始、何时结束、失败了怎么退、资源谁来清理。最容易被忽略的，其实是 context 的传播深度和 channel 的关闭时机 —— 这两个点一旦出错，问题往往延迟暴露，调试成本远高于加几行锁。
