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<- int（只发）、<-chan int（只收），编译期防误写 - 缓冲大小选 0 还是 N？无缓冲适合强同步（如等待确认），有缓冲适合解耦（如日志暂存），但别为了“省一次 goroutine 切换”而滥用大 buffer
别用 chan 模拟锁，性能差还语义错
用 ch <- struct{}{} + <-ch 实现互斥，本质是拿 channel 当锁使。基准测试显示：高并发下，这种写法比 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 成本远高于初期选型成本。
