必须用 sync.mutex 或 sync.rwmutex 保护共享变量，chan 模拟锁属语义错误、性能倒退且易死锁；并发写 map 必 panic，结构体字段同理；读多写少用 rwmutex；chan 应用于任务分发、事件通知等协作场景，非状态同步。
改共享变量必须用 sync.Mutex 或 sync.RWMutex，用 chan 模拟锁是错的——不是“不推荐”，是语义错误 + 性能倒退 + 死锁高发。
并发写 map 或结构体字段时，必须用 sync.Mutex
Go 运行时对 map 并发写有硬性 panic 检查：fatal error: concurrent map writes。这不是竞态警告，是立即崩溃。同理，结构体中多个 goroutine 同时写同一字段、递增全局计数器，也会静默错乱或 panic。
-
chan struct{}收发一次 ≠ 临界区保护：它只延迟了执行时机，不阻止 goroutine 进入临界区，竞态照旧 - 正确做法是把 map 操作包在
mu.Lock()/mu.Unlock()之间，哪怕只是m[key] = val - 读多写少（如配置快照、服务状态）优先用
sync.RWMutex，RLock()允许多读，Lock()写时才阻塞全部
分发任务、通知事件、编排退出流程，必须用 chan
chan 不是用来“同步访问变量”的，它是表达“谁提供、谁消费、谁退出”的协作契约。强行用它保护状态，等于把螺丝刀当锤子使。
- worker pool 分发任务：用
jobs chan int，每个 goroutinefor j := range jobs，天然解耦 - 配置热更后广播：
done chan struct{}关闭即通知所有监听者，比轮询或锁检查干净得多 - 超时控制必须配
select：比如select { case ，<code>Mutex做不到 - 别用
chan int轮询“取最新值”——这是状态同步，该用atomic.LoadInt64(&counter)或带锁字段
sync/atomic 比两者都轻，但只适用于单个整数
如果只是递增计数器、开关布尔标志、存指针地址，atomic 是最优解：零分配、无调度、无锁、纳秒级。
-
atomic.AddInt64(&count, 1)替代mu.Lock(); count++; mu.Unlock() -
atomic.CompareAndSwapInt32(&state, 0, 1)实现一次性初始化（配合sync.Once更稳） - 但不能用于 map、slice、struct 整体——这些操作不是原子的，
atomic无法覆盖 - 注意：
atomic不提供内存屏障语义以外的同步，别指望它让其他字段“顺便”可见
真实系统里，sync.Mutex 和 chan 经常组合使用
它们不是二选一，而是分工明确：一个管“数据安全”，一个管“事件通知”。标准库全这么干——sync.Map 用锁，net/http 连接池用锁，但连接关闭通知用 done chan struct{}。
- 缓存更新场景：
mu.Lock()写 map，写完后select { case notifyCh 发通知，缓冲 <a style="color:#f60; text-decoration:underline;" title="channel" href="https://m.php.cn/zt/22725.html" target="_blank">channel</a> 防阻塞 - 生产者负责
close(notifyCh)，消费者绝不 close；用chan / <code> 标注方向，编译期防误写 - 切忌把
http.Get、db.Query、time.Sleep放进锁内——IO 阻塞会拖垮所有等待 goroutine - 锁粒度要细：不要整个 handler 包进
mu.Lock()，只锁真正共享的那几行
最容易被忽略的一点：channel 的所有权和关闭责任必须清晰。反复 close 同一个 channel 会 panic，向已关闭的 channel 发送也会 panic——这和 mutex 的“多次 Unlock”一样，是运行时硬错误，不是逻辑 bug。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
