go程序启动 goroutine 后，主协程不会自动等待其完成，若未使用 w aitgroup、channel 等 同步机制，可能在 goroutine 尚未执行完毕时就打印空切片——这是因缺乏同步导致的竞态与提前退出问题。
在 Go 中，go 关键字启动的 goroutine 是 异步且非阻塞 的：主 goroutine（即 main 函数）会立即继续执行后续语句，而不会等待新协程结束。在你提供的代码中：
go fill(&b1, 10) go fill(&b2, 10) fmt.Println(b1, b2) // ← 此时两个 goroutine 极大概率尚未执行完 fill 逻辑！fmt.Println 几乎总在 fill 函数修改切片前执行，因此输出为[] []。更严重的是，main 函数结束后整个程序立即终止——所有仍在运行的 goroutine 会被强制回收，根本无机会完成工作。
✅ 正确做法：使用 sync.WaitGroup 显式同步
WaitGroup 是 Go标准库 中专为“等待一组 goroutine 完成”设计的轻量级同步原语。其核心三步：
立即学习“go 语言免费学习笔记（深入）”；
- Add(n) —— 声明需等待的 goroutine 数量；
- 每个 goroutine 末尾调用 Done() —— 表示自身已完成；
- 主 goroutine 调用 Wait() —— 阻塞直至计数归零。
修正后的完整可运行代码如下：
package main import ("fmt" "math/rand" "sync" "time") var (b1 []float64 b2 []float64) func main() { // 初始化随机数种子（否则 rand.Float64()每次运行结果相同）rand.Seed(time.Now().UnixNano()) var wg sync.WaitGroup wg.Add(2) // 预期等待 2 个 goroutine go fill(&b1, 10, &wg) go fill(&b2, 10, &wg) wg.Wait() // 主 goroutine 在此阻塞，直到两个 fill 都调用 Done() fmt.Println("b1 =", b1) fmt.Println("b2 =", b2) } func fill(a *[]float64, n int, wg *sync.WaitGroup) {defer wg.Done() // 确保无论何种路径退出，都执行 Done() for i := 0; i < n; i++ { *a = append(*a, rand.Float64()*100) } }⚠️ 关键注意事项：
- 必须导入 "math/rand" 和 "time"：原代码缺失 rand 包，且未初始化种子，会导致重复随机数；
- wg.Done() 应放在 defer 中 ：避免因 panic 或提前 return 导致计数未减少，引发 Wait() 永久阻塞；
- *传递 `sync.WaitGroup 而非值 **：WaitGroup` 内部含互斥锁，按值传递会复制状态，失去同步效果；
- 不要依赖 fmt.Scanln“凑合等待”：该方式不可靠、不优雅，且掩盖了根本的同步缺失问题。
? 进阶建议：更符合 Go 惯用法的写法是 避免共享变量 + 返回新切片，例如：
func fill(src []float64, n int) []float64 { for i := 0; i < n; i++ { src = append(src, rand.Float64()*100) } return src } // 调用侧：b1 = fill(b1, 10) b2 = fill(b2, 10)若坚持并发，可配合 channel 收集结果：
ch := make(chan []float64, 2) go func() { ch <- fill(nil, 10) }() go func() {ch <- fill(nil, 10) }() b1, b2 = <-ch, <-ch总结：Go 的并发模型强调 显式同步 。永远不要假设 goroutine“应该已经跑完了”——用 WaitGroup、channel 或 sync.Once 等 工具 明确表达依赖关系，才能写出正确、可维护的并发程序。
