goroutine 启动后数据没更新是因为主 goroutine 未等待其执行完成，需用 sync.WaitGroup 或 channel 显式同步，否则因竞态或闭包捕获循环变量导致结果异常。
goroutine 启动后数据没更新，是因为没等它执行完
Go 中启动 go func() 是异步的，主 goroutine 不会自动等待子 goroutine 结束。常见现象是：转换逻辑写对了，但 fmt.Println 打印出来还是原始值或空结果。
必须显式同步——最常用的是 sync.WaitGroup：
var wg sync.WaitGroup
for _, item := range data {
wg.Add(1)
go func(v string) {
defer wg.Done()
// 转换逻辑，比如 v = strings.ToUpper(v)
result = append(result, v) // 注意：需加锁或用 channel 收集
}(item)
}
wg.Wait() // 主 goroutine 在这里阻塞，直到所有子任务完成容易踩的坑：
- 忘记调用
wg.Add(1)，导致Wait()立即返回 - 在循环里直接传
item变量（而非副本），闭包捕获的是循环变量地址，最后所有 goroutine 都处理同一个值 - 多个 goroutine 并发写同一 slice（如
result）而没加锁或没用 channel，引发 panic 或数据丢失
用 channel 安全收集并发转换结果
比共享变量 + mutex 更符合 Go 习惯的方式：每个 goroutine 把结果发到 channel，主 goroutine 从 channel 接收。天然避免竞态，也隐含同步语义。
立即学习“go语言免费学习笔记（深入）”；
典型结构：
ch := make(chan string, len(data)) // 缓冲 channel 避免 goroutine 阻塞
for _, item := range data {
go func(v string) {
ch <- strings.TrimSpace(v) // 示例：去空格
}(item)
}
// 关闭 channel 的时机很重要：不能在循环里关，得另起 goroutine 或等所有发送完
go func() {
for range data {
<-ch // 接收并处理
}
close(ch)
}()更稳妥的做法是用 sync.WaitGroup 控制发送端，再关闭 channel：
ch := make(chan string, len(data))
var wg sync.WaitGroup
for _, item := range data {
wg.Add(1)
go func(v string) {
defer wg.Done()
ch <- strings.ToUpper(v)
}(item)
}
go func() {
wg.Wait()
close(ch)
}()
// 主 goroutine 从 ch 读取
for res := range ch {
results = append(results, res)
}大量数据时，不加限制的 goroutine 会耗尽内存或触发调度抖动
每启动一个 goroutine 至少占用 2KB 栈空间。如果 data 有 10 万条，直接起 10 万个 goroutine，很可能 OOM 或被调度器惩罚（表现为延迟突增、CPU 利用率异常低）。
应控制并发数，常用做法是 worker pool：
const workers = 8
ch := make(chan string, len(data))
done := make(chan struct{})
// 启动固定数量 worker
for i := 0; i < workers; i++ {
go func() {
for v := range ch {
// 转换逻辑
result := strings.ReplaceAll(v, " ", "_")
// 发送到结果 channel 或写入共享结构（需加锁）
}
}()
}
// 发送任务
for _, item := range data {
ch <- item
}
close(ch)
// 等待所有 worker 退出（可选：用 WaitGroup 更精确）
time.Sleep(time.Millisecond * 10)关键点：
- worker 数量不是越多越好，通常设为
runtime.NumCPU()的 1–2 倍较稳妥 - 输入 channel 要缓冲（
make(chan T, N)），否则第一个 worker 卡住会导致整个流程停滞 - 不要依赖
time.Sleep等待，应通过 channel 关闭 +range或WaitGroup精确同步
转换逻辑含阻塞操作（如 HTTP 请求、DB 查询）时，超时控制必不可少
单个 goroutine 卡住（比如下游服务响应慢），会拖垮整个批量处理。必须为每个转换任务设置上下文超时：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
go func(ctx context.Context, v string) {
select {
case <-time.After(3 * time.Second): // 模拟耗时转换
result := transform(v)
outputCh <- result
case <-ctx.Done():
outputCh <- "" // 或错误标记
return
}
}(ctx, item)更推荐用 context.WithTimeout 包裹实际调用：
go func(v string) {
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
res, err := doHTTPTransform(ctx, v) // 该函数内部用 ctx.Done() 检查中断
if err != nil {
outputCh <- ""
return
}
outputCh <- res
}(item)注意：context 超时只对支持 context 的 API（如 http.Client.Do）有效；纯 CPU 计算需手动轮询 ctx.Done()。
真正难处理的是那种既没 context 参数、又无法拆解的黑盒函数——这时候只能靠启动 goroutine + select 等待，但无法主动中断它，只能容忍超时后丢弃结果。
