go并发编程中必须用sync.mutex或sync.rwmutex保护共享变量，map/结构体字段/计数器等并发读写需加锁；atomic适用于单个整数；channel用于通信而非同步，严禁模拟锁；真实系统常组合使用二者，职责分明。

改共享变量必须用 sync.Mutex 或 sync.RWMutex

Go 运行时对并发写 map、结构体字段、计数器等共享内存有严格检查，不加锁直接并发修改会 panic：fatal error: concurrent map writes 或静默数据错乱。这不是警告，是硬性崩溃。

常见误判：以为“用 channel 收发一次就能同步”，比如开个 chan struct{} 做信号，然后在收发之间读写 map —— 这根本没保护临界区，只是加了一层调度延迟，竞态照旧。

• 只要操作涉及 map、struct 字段、全局配置、缓存快照，就必须用 mu.Lock()/mu.RLock()
• 读多写少（如服务健康状态、配置快照）优先用 sync.RWMutex，避免读操作互相阻塞
• 单个整数计数器？直接上 atomic.AddInt64，比锁和 channel 都轻
• 别把 http.Get、db.Query、time.Sleep 放进 mu.Lock() 和 mu.Unlock() 之间——锁粒度太粗，等于让所有 goroutine 排队等 IO

分发任务、通知事件、编排流程必须用 chan

当你需要表达“谁提供、谁消费、谁退出”这种协作关系时，chan 不是选项，是自然解法。Mutex 做不到这点，强行模拟只会让逻辑缠绕、死锁难查。

典型场景包括：worker pool 分发任务、日志 pipeline 转发、配置热更后广播 done chan struct{}、配合 select 实现超时控制。

• 用 chan int 轮询“取最新值”？这是状态同步，该用原子操作或带锁字段，不是 channel 的职责
• 向已关闭的 chan 发送数据会 panic；反复 close 同一个 chan 也会 panic —— 生产者负责 close，消费者绝不 close
• 明确标注方向：chan（只发）、<code>（只收），编译期防误写
• 缓冲大小选 0 还是 N？无缓冲适合强同步（如等待确认），有缓冲适合解耦（如日志暂存），但别为了“省一次 goroutine 切换”而滥用大 buffer

别用 chan 模拟锁，性能差还语义错

用 ch + <code> 实现互斥，本质是拿 channel 当锁使。基准测试显示：高并发下，这种写法比 <code>sync.Mutex 慢 3–5 倍，因为每次收发要两次 hchan 内部锁 + buffer copy，而 Mutex 是一次原子操作。

更糟的是语义混淆：别人看到 ch ，第一反应是“发消息”，结果你是在抢临界区——代码可读性和可维护性直接受损。

• 低竞争时差距不明显，但一到压测环境，channel 模拟锁的延迟抖动会立刻暴露
• 标准库里所有共享状态保护（sync.Map、net/http 连接池）全用 Mutex，没一个靠 channel
• 如果真需要“带超时的锁等待”，用 sync.Mutex 配合 time.AfterFunc 或 context，别硬套 channel

复杂场景常需 sync.Mutex 和 chan 组合

真实系统里，纯通信或纯保护都少见。比如缓存更新：写入时用 mu.Lock() 保 map 安全，更新完再往 updateCh chan string 发个 key 通知监听者——锁管数据一致性，channel 管事件解耦。

这种组合不是折中，是分层：Mutex 守住临界区边界，channel 在边界外传递意图。混用的前提是职责清晰，否则就变成两套同步机制互相打架。

• 配置热更：Mutex 写新配置，channel 广播 “config updated”
• 状态广播：Mutex 更新 status 字段，channel 推送变更事件给监控 goroutine
• 任务调度器：Mutex 管理任务队列状态，channel 发送完成信号给结果处理器
• 切记：channel 的发送/接收本身不保护任何共享变量，它只是个信号管道

关键点始终落在“操作对象”上：你在动内存，就用 Mutex；你在传消息，就用 chan。错位使用，问题不会立刻爆发，但会在高负载、长周期运行时突然浮现——那时 debug 成本远高于初期选型成本。