该用 sync.Mutex 而非 chan 时：保护小粒度共享内存读写（如计数器、字段更新），无需协程协作；chan 适用于解耦生产消费、传递语义化消息（如任务、信号、超时）。
什么时候该用 sync.Mutex 而不是 chan
当你要保护一段共享内存的读写，且操作粒度小、不涉及协程协作逻辑时，sync.Mutex 更直接。比如更新一个计数器、修改结构体字段、缓存命中后填充值——这些都不需要“通知别人我改完了”，只需要“别同时改”。
常见错误是强行用 channel 做互斥：开一个容量为 1 的 chan struct{}，每次操作前 select 发送，完后再接收。这不仅多出 goroutine 调度开销，还掩盖了本质是“临界区保护”的事实。
- 适合场景：
map并发读写（需配合sync.RWMutex）、全局配置热更新、对象状态标记 - 注意点：避免在锁内做阻塞操作（如 HTTP 调用、数据库查询），否则会拖慢所有等待者
- 性能差异：Mutex 加锁/解锁是纳秒级；channel 操作至少微秒级，尤其带缓冲或跨 goroutine 时
什么时候必须用 chan 而不能用锁
当你需要解耦生产与消费节奏、协调多个 goroutine 的执行顺序、或者传递数据本身带有语义（比如“任务来了”“结果好了”“该退出了”），channel 是唯一自然的选择。锁解决不了“谁来处理这个请求”，只解决“谁能改这个变量”。
典型误用：用 Mutex 包裹一个队列，然后轮询检查是否有新任务——这既浪费 CPU，又无法响应中断。而 chan 天然支持阻塞等待、超时控制、select 多路复用。
立即学习“go语言免费学习笔记（深入）”；
- 适合场景：worker pool 分发任务、信号通知（如
done chan struct{}）、流式数据处理（日志、metrics）、超时控制（time.After配合select） - 参数差异：无缓冲 channel 是同步点，有缓冲 channel 是有限缓冲区；别默认设大缓冲，容易掩盖背压问题
- 容易踩的坑：
close已关闭的 channel 会 panic；向已关闭的 channel 发送也会 panic；只从 channel 读不关它，可能造成 goroutine 泄漏
sync.Once 和 chan 在初始化场景中的取舍
单次初始化（如加载配置、连接数据库）首选 sync.Once，而不是用 channel 等待某个 “init done” 信号。后者要额外管理 goroutine 生命周期、channel 关闭时机，还可能因忘记关闭导致死锁。
sync.Once 内部用原子操作+Mutex 实现，轻量且语义清晰；它的 Do 方法保证函数最多执行一次，且所有调用者会阻塞直到完成——这正是你想要的“等初始化完再继续”。
- 反例：起一个 goroutine 做初始化，用
chan bool通知完成。若初始化失败，channel 可能永远不写入，调用方永久阻塞 - 正解：把初始化函数传给
once.Do(func(){...})，失败时在函数内记录错误，后续调用可检查错误变量 - 注意：
sync.Once不处理错误传播，错误需自行保存到包级变量或返回值中
混合使用时的关键边界：别让 channel 成为锁的替身
常见设计陷阱是用 channel 封装状态变更，比如定义 type Cmd int; const Inc Cmd = iota; Dec，再起一个 goroutine 从 chan Cmd 里读指令并更新变量。表面看“没有锁”，实际只是把锁逻辑移到了单个 goroutine 内部——它仍是串行处理，且引入了额外调度和内存分配。
这种写法只有在需要异步化 + 命令合并（如防抖）或跨进程边界时才有意义。如果只是保护一个整数，sync/atomic 或 sync.Mutex 更合适。
- 真正值得封装成 channel 的操作：涉及 IO、网络、外部依赖，或需要与其他事件交叉响应（如定时器 + 用户输入）
- 性能提示：频繁发送小结构体到 channel 会产生大量堆分配；可考虑复用对象或使用指针 + 同步池
- 最易忽略的一点：channel 的方向性（
/chan）是编译期契约，但 runtime 不强制检查；把双向 channel 当单向用，可能在后期重构中意外破坏隔离性
