因为sync.Mutex是全局锁，所有goroutine竞争同一把锁，分片失效；正确做法是每个分片配独立锁，用哈希函数（如murmur3）和2的幂次分片数实现均匀路由。
为什么直接用 map + sync.Mutex 写分片写入会卡死？
因为 sync.Mutex 是全局锁，所有 goroutine 都在抢同一把锁，分片就白做了。真正要的是「每个分片一把独立锁」，而不是把数据分了但锁没分。
常见错误是：先按 key 哈希算出分片索引，再统一用一个 sync.RWMutex 包裹整个 map —— 这等于给高速公路修了一个收费站，车再多也得排队。
- 正确做法：用
[]sync.RWMutex或sync.Map配合分片数组，让每个分片有专属读写锁 - 哈希函数别用
hash/fnv简单取模，要防哈希倾斜，建议用int64(key) % int64(shardCount)（key 为整型）或murmur3.Sum64()（key 为字符串） - 分片数建议设为 2 的幂次（如 32、64），方便位运算优化：
shardIdx := uint64(key) & (uint64(shardCount)-1)
如何避免 write-after-read 竞态导致数据丢失？
典型场景：多个 goroutine 同时对同一个 key 执行「读-改-写」，比如计数器累加。即使分片锁分开，read-modify-write 仍可能覆盖彼此。
不能靠 map[key]++ 这种非原子操作，必须用带锁的原子更新逻辑。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 对数值类字段，优先用
sync/atomic（如atomic.AddInt64(&shard.counts[key], 1)），前提是 key 能映射到固定内存地址（例如用预分配的[]int64+ 哈希寻址） - 否则必须在分片锁内完成完整读写：
shard.mu.Lock(); v := shard.data[key]; shard.data[key] = v + 1; shard.mu.Unlock() - 千万别在锁外读、锁内只写——这是经典竞态：A 读旧值，B 读旧值，A 写新值，B 写新值，结果只 +1
分片结构体怎么设计才不逃逸、不拖慢 GC？
如果每个分片都用 map[string]interface{}，小对象高频分配会让 GC 压力飙升，且 interface{} 会装箱导致额外内存开销和间接寻址。
真实高性能场景中，数据结构往往已知（比如全是 int64 计数器），应避免泛型抽象过早引入。
- 定义固定类型分片：
type Shard struct { mu sync.RWMutex; counts map[uint64]int64 }，key 用uint64替代string可省哈希和内存分配 - 初始化时预分配 map 容量：
make(map[uint64]int64, 10000)，避免运行时多次扩容 - 如果 key 来源可控（如用户 ID 是 int64），直接用数组替代 map：
counts [65536]int64，索引即 key % cap，零分配、零锁、纯原子操作
goroutine 泄漏和写入吞吐瓶颈在哪？
很多人起一堆 goroutine 往分片里塞数据，结果发现 CPU 没跑满、QPS 卡在 1w 就上不去——问题常出在 channel 缓冲区或锁粒度之外的隐藏串行点。
- 别用无缓冲 channel 做写入队列：
ch := make(chan Item)，这会让生产者阻塞等待消费者，实际变成单线程写入 - channel 缓冲区大小至少设为并发 goroutine 数 × 平均批大小，例如 32 个 worker，每批 100 条，缓冲区至少
make(chan Item, 3200) - 检查是否在写入路径中调用了阻塞 I/O（如日志打印、HTTP 请求、未缓存的数据库查询），这些会拖垮整个分片 goroutine
- 用
runtime.ReadMemStats对比前后 Alloc 和 PauseNs，确认不是 GC 在频繁 stop-the-world
分片数不是越多越好，超过 CPU 核心数太多反而增加调度开销；实测时建议从 8 片起步，压测看 lock contention 和 cache line false sharing 是否上升。
