高并发性能骤降主因是goroutine竞争锁、map或gc；应细化锁粒度、避免局部mutex、读多写少用rwmutex、map并发需分片或sync.map、计数器优先atomic。
高并发下性能骤降，八成不是 CPU 或网络瓶颈，而是 goroutine 之间争同一把锁、抢同一个 map、或反复触发 GC——这些竞争行为本身就会吃掉大量调度和内存开销。
sync.Mutex 锁粒度太大，直接卡死吞吐
一把 sync.Mutex 包住整个 map[string]int，所有读写都排队，QPS 上不去是必然的。这不是锁不够快，是它保护了不该保护的东西。
- 只对真正需要互斥的字段或操作加锁，比如只锁「更新计数」那段逻辑，别把日志打印、HTTP 调用也裹进去
- 绝不要把
sync.Mutex声明为函数局部变量——每次调用都新建一把锁，等于没锁 - 写多读少？老老实实用
sync.Mutex；读多写少（如配置缓存）？换成sync.RWMutex，但注意：RLock()和RUnlock()必须成对出现，漏一个就可能读到脏数据
map 并发读写 panic 不是偶然，是设计缺陷
fatal error: concurrent map writes 这类 panic 出现时，说明代码里有至少两个 goroutine 在没同步的情况下往同一个 map 写——Go 运行时直接终止程序，不给你机会静默错乱。
- 别指望「我只读不写就安全」：map 的扩容机制会让读操作也触发写，所以读写都必须受同一把锁保护
- 高频写场景优先考虑分片：比如用 64 个
map+ 64 把sync.Mutex，key 按哈希分散，冲突概率下降几十倍 - 纯读场景可提前生成不可变副本（如
map[string]struct{}转为sync.Map或atomic.Value存整张表），避免运行时加锁
atomic 不是万能，但简单计数必须用它
用 sync.Mutex 保护一个 int64 计数器，是典型的“大炮打蚊子”。调度器要挂起 goroutine、切上下文、抢锁、再恢复——而 atomic.AddInt64 一条 CPU 指令就搞定。
- 仅限单一变量的原子读写或 CAS：计数器、开关标志、指针替换（
atomic.Value） - 禁止拆解操作：
counter++必须写成atomic.AddInt64(&counter, 1)，不能先Load再Store - 复合逻辑（如「如果 count atomic.CompareAndSwapInt64，否则仍存在竞态窗口
channel 不是银弹，滥用反而加重竞争
用 channel 替代共享变量本意是好的，但若所有 goroutine 都往同一个无缓冲 chan int 发送，本质还是在排队——底层仍是锁实现的。
- 发送端阻塞在
ch ？检查接收端是否已退出、是否漏关 channel、是否有 goroutine 没消费完就结束了 - 高频小数据传递建议用带缓冲 channel（如
make(chan int, 1024)），减少调度等待 - worker pool 场景下，别让每个 worker 自己开 channel，统一由 dispatcher 分配任务，避免 channel 创建/销毁开销
最常被忽略的一点：竞争问题往往藏在「看起来没问题」的地方——比如日志中间件里一次同步 Redis INCR，或配置热更新时对全局 map 的非原子赋值。上线前跑 go run -race，比压测发现更早、代价更低。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
