必须用 sync.Mutex 或 sync.RWMutex 保护共享内存的非原子读写；优先用 atomic 处理单个整数/指针的简单操作；channel 适用于通信协作而非替代锁；复杂状态需锁、channel、WaitGroup、atomic 组合使用。
共享内存修改必须用 sync.Mutex 或 sync.RWMutex
当多个 goroutine 同时读写同一块内存（比如一个全局 map、计数器 int、或结构体字段），且写操作不是原子的，就必须加锁。go 的 map 本身不支持并发写，直接写会 panic：fatal Error: concurrent map writes；即使只是“读+写”组合（如 counter++），也非原子，必须保护。
实操建议：
-
sync.Mutex适用于读写都较频繁、或写操作占比较高的场景 -
sync.RWMutex更适合读多写少（比如配置缓存、状态快照），允许多个 goroutine 同时读，但写时会独占 - 锁粒度要细：不要对整个函数加锁，优先锁具体字段或局部数据结构；避免把
http.Handler整个方法体包在mu.Lock()里 - 务必检查锁的生命周期：不要在 defer 中 unlock 一个未 lock 的 mutex，也不要跨 goroutine 传递已 lock 的 mutex
channel 更适合 goroutine 间协作与流程控制
channel 不是“替代锁的通用方案”，而是为通信而生。它天然适合表达“谁等谁”“谁通知谁”“谁提供数据谁消费数据”这类关系。比如 worker pool、任务分发、信号通知（done channel）、超时控制（select + time.After）。
常见误用：
- 用
chan Struct{}当作“锁开关”来保护临界区——这本质是用 channel 模拟锁，但语义不清、易死锁、性能更差 - 为每个简单计数器开一个
chan int，再起 goroutine 去收——过度工程，远不如atomic.AddInt64或mu.Lock()直观高效 - 在 hot path（如每毫秒调用一次的统计函数）中使用 unbuffered channel —— 会强制 goroutine 切换和调度开销，比锁还重
能用 atomic 就别用锁或 channel
对单个整数、指针、unsafe.pointer 的读写，sync/atomic 提供零分配、无锁、高性能的原子操作。它比 mutex 轻量得多，也比 channel 更直接。
适用条件明确：
- 操作目标是
int32、int64、uint32、uint64、uintptr、unsafe.Pointer或其指针 - 只需要基础操作：增减（
atomic.AddInt64）、比较并交换（atomic.CompareAndSwapInt64）、加载（atomic.LoadInt64）、存储（atomic.StoreInt64） - 不需要复合逻辑（比如“如果值小于 100 才加 1”且该判断+写入需原子）——这时得回退到 mutex
var counter int64 // 安全：原子增 atomic.AddInt64(&counter, 1) // 危险：非原子，竞态 counter++复杂状态同步往往需要锁 + channel 组合
纯 channel 很难表达“带状态的响应式行为”。例如实现一个带缓冲、可关闭、支持等待所有任务完成的 job queue，通常要：
- 用 channel 接收新任务（通信）
- 用
sync.WaitGroup记录活跃 worker（协作生命周期） - 用
sync.RWMutex保护内部状态（如当前积压任务数、是否已关闭） - 用
atomic.bool标记关闭信号（轻量状态）
单独依赖某一种机制，容易在边界情况（如关闭中又投递任务、worker panic 后状态残留）下出错。真正健壮的并发组件，往往是多种原语按职责混合使用。
最容易被忽略的是：锁和 channel 的错误处理路径是否一致。比如在 select 中从 channel 收消息后 panic 了，mutex 是否仍处于 locked 状态？这类问题不会报编译错误，但会导致后续 goroutine 永久阻塞。