必须用 sync.Mutex 保护共享变量，不可用 chan 模拟锁；多 goroutine 读写 map、结构体字段等会触发 fatal error: concurrent map writes 并立即崩溃。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
改共享变量必须用 sync.Mutex，别碰 chan
当你在多个 goroutine 里读写同一个 map[string]int、结构体字段、切片或缓存快照时，sync.Mutex 是唯一安全的选择。Go 运行时会直接 panic：fatal error: concurrent map writes，这不是警告，是立即崩溃。用 chan 模拟锁（比如开个 chan struct{} 然后每次操作前 select { case ）语义错乱、调度开销大、还容易死锁。
<ul>
<li>map、slice、struct 字段更新：必须用 <code>mu.Lock()/mu.Unlock()
sync.RWMutex，RLock() 不互斥，吞吐更高atomic.AddInt64，比锁更轻，零分配、无调度http.Get、db.Query、time.Sleep 都得挪到锁外，否则卡住所有等待者分发任务或通知状态必须用 chan，别用 Mutex
当你需要让 goroutine 协作——比如启动 worker 池、广播“配置已更新”、实现超时退出、或构建日志 pipeline——chan 不是选项，是自然解法。它自带同步语义：ch 会阻塞直到有人接收，这是 <code>Mutex 根本做不到的。
- 任务分发：用
jobs := make(chan int, 10)+ 多个 worker goroutine 从里面取 - 信号通知：比如
done chan struct{}或updateCh chan string，消费者for range监听 - 超时控制：必须配合
select使用ctx.Done()，time.After无法取消，会泄漏 timer - 关闭 channel 是唯一安全的“广播结束”方式；反复
close同一个 channel 会 panic
两者组合用得对，代码才真正清晰
复杂场景下，sync.Mutex 和 chan 不是二选一，而是分工明确：锁保护临界区，channel 解耦通信。比如热更新配置——写入新配置时用 mu.Lock() 保证 map 安全，写完立刻发消息到 updateCh，监听协程收到后 reload，不侵入锁内逻辑。
- 所有权要明确：生产者 close channel，消费者绝不 close；用
chan 或 <code> 标注方向，防误写 - 别用
chan int传“最新值”，比如轮询式想拿当前计数器——这是状态同步，该用原子操作或带锁字段 - 缓冲 channel 要设合理容量：太小易阻塞写入，太大内存浪费；
make(chan string, 10)常见于事件通知 - 向已关闭的 channel 发送数据会 panic；接收则得零值并继续执行，可用
v, ok := 判断是否关闭
性能和可维护性陷阱常被忽略
纳秒级的 mu.Lock() 和微秒级的无缓冲 chan 收发，差距不是一个数量级。高频小数据通信（如每毫秒一次状态更新），atomic.Value + sync.RWMutex 比 chan struct{} 更稳。而用 channel 模拟锁、在循环里反复创建无缓冲 channel、把整个 HTTP handler 包进一个 lock ——这些不是“高级用法”，是给自己埋雷。
- 锁粒度要细：只锁真正共享的部分，别把网络调用、模板渲染全包进去
- channel 不是万能胶：它不解决竞态，只传递消息；想靠它“同步访问变量”是误用
- 不要因为“Go 主张用 channel”就硬套：Mutex 零值可用、语义直白、性能高，该用就用
- 最易被忽视的一点：context.WithTimeout 必须和 select 配合才有意义，单独调用等于没写
