go程序启动goroutine后，主协程不会自动等待其完成，若未使用waitgroup、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等工具明确表达依赖关系，才能写出正确、可维护的并发程序。
