直接用 sync.WaitGroup + for range 分片出错，是因为未显式复制循环变量，导致所有 goroutine 共享同一 slice 引用或 index 值，引发竞态或漏处理。
为什么直接用 sync.WaitGroup + for range 分片会出错
常见误区是把一个大任务切分成 N 个子切片，然后每个 goroutine 处理一个——但若不显式复制循环变量，所有 goroutine 实际共享同一个 slice 引用或 index 值，导致竞态或漏处理。比如：
for i := 0; i < len(tasks); i += chunkSize {
go func() {
process(tasks[i:min(i+chunkSize, len(tasks))])
}()
}这里 i 是闭包捕获的变量，最终所有 goroutine 看到的都是循环结束后的值。
正确做法是把分片参数作为函数参数传入，或在循环内用局部变量绑定：
for i := 0; i < len(tasks); i += chunkSize {
start, end := i, min(i+chunkSize, len(tasks))
go func(s, e int) {
process(tasks[s:e])
}(start, end)
}
用 runtime.GOMAXPROCS 控制并发度不如用带缓冲的 chan 精确
设置 GOMAXPROCS 只影响 OS 线程调度上限，不控制实际并发的 goroutine 数量；而真实场景中你往往想限制“同时最多处理 N 个分片”，避免内存暴涨或下游压垮。这时应使用 worker pool 模式：
- 创建容量为
N的chan struct{}作信号量 - 每个 goroutine 启动前先
，完成后 <code>sem - 或更推荐：用
chan Task+ 固定数量的 worker goroutine 消费，天然限流
示例节选：
sem := make(chan struct{}, 4) // 最多 4 个并发
for _, chunk := range chunks {
sem <- struct{}{} // 阻塞直到有空位
go func(c []Task) {
defer func() { <-sem }() // 归还信号
process(c)
}(chunk)
}
sync.Map 不适合收集分片结果，改用预分配切片 + atomic 索引
多个 goroutine 写结果时，若用 sync.Map.Store 或 map + sync.Mutex，写放大明显且无序。实际分片编号固定（如第 0 片、第 1 片……），最优解是预先分配结果切片，用原子操作推进写位置：
- 初始化
results := make([]Result, len(chunks)) - 启动 goroutine 时传入分片索引
idx - 处理完后执行
atomic.StoreUintptr(&results[idx], uintptr(unsafe.Pointer(&r)))（简单场景直接赋值也安全，因索引不重叠）
注意：只要每个 goroutine 只写自己对应的 results[i]，完全不需要锁或原子操作——这是分片设计的核心优势，别自己加锁破坏它。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
分片边界计算必须用 min(i+size, len(data))，不能只靠 i+size
当 len(data) 不能被 chunkSize 整除时，最后一片长度会小于 chunkSize。如果循环条件写成 i+chunkSize ，最后一片会被跳过。
立即学习“go语言免费学习笔记（深入）”；
安全写法只有这一种：
for i := 0; i < len(data); i += chunkSize {
end := i + chunkSize
if end > len(data) {
end = len(data)
}
chunk := data[i:end]
// ...
}或者更简洁：end := min(i+chunkSize, len(data))（需自行定义 min 或用 int(math.Min(float64(i+chunkSize), float64(len(data))))，但整数比较更快）。
这个细节漏掉，轻则任务少执行，重则 panic: slice bounds out of range。
