主 goroutine 过早退出会导致其他 goroutine 未执行即终止；应使用 sync.WaitGroup（Add 在 go 前调用）、channel 或 time.Sleep 等方式等待，避免程序提前结束。
goroutine 启动后不执行？检查是否主 goroutine 过早退出
Go 程序启动时只运行 main 函数所在的 goroutine，其他 goroutine 是异步调度的。如果 main 函数结束，整个程序立即退出，所有正在运行的 goroutine 都会被强制终止。
常见错误写法：
func main() {
go func() {
fmt.Println("hello from goroutine")
}()
// main 直接返回，goroutine 很可能没来得及打印就结束了
}
正确做法是让 main 等待子 goroutine 完成，常用方式包括：
- 用
time.Sleep()临时阻塞（仅用于演示，不可用于生产） - 用
sync.WaitGroup精确等待一组 goroutine 结束 - 用
channel接收完成信号（适合有返回值或需同步状态的场景）
sync.WaitGroup 使用要点：Add 必须在 goroutine 启动前调用
WaitGroup 的 Add() 方法必须在 go 语句之前调用，否则可能出现竞态：goroutine 已执行完并调用 Done()，而 Add() 还没执行，导致 Wait() 永远阻塞或 panic。
立即学习“go语言免费学习笔记（深入）”；
错误示例：
var wg sync.WaitGroup
for i := 0; i < 3; i++ {
go func() {
defer wg.Done()
fmt.Printf("task %d\n", i)
}()
wg.Add(1) // ❌ 错了！Add 在 go 后面，顺序不可靠
}
正确写法：
var wg sync.WaitGroup
for i := 0; i < 3; i++ {
wg.Add(1) // ✅ 必须放前面
go func(id int) {
defer wg.Done()
fmt.Printf("task %d\n", id)
}(i)
}
注意：循环变量 i 需显式传入闭包，否则所有 goroutine 可能读到同一个最终值（常见陷阱）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
goroutine 泄漏：忘记关闭 channel 或未消费的发送操作
向一个没有接收方的无缓冲 channel 发送数据，会永久阻塞该 goroutine；若该 goroutine 持有资源（如文件句柄、数据库连接），就构成泄漏。
典型泄漏场景：
- 启动 goroutine 向 channel 写入，但主 goroutine 没有从该 channel 读取
- 使用
select时未设default分支，且所有 case 都无法就绪 - goroutine 中死循环 + channel 发送，但接收端已退出
简单检测方式：运行时加 -gcflags="-m" 查看逃逸分析，或用 pprof 观察 goroutine 数量持续增长。
runtime.Gosched() 不是“让出 CPU”，而是提示调度器可切换
runtime.Gosched() 并不会真正挂起当前 goroutine，它只是向 Go 调度器发出一个建议：“我现在可以被抢占，请考虑调度其他 goroutine”。是否切换、切给谁，完全由调度器决定。
它主要用于避免长时间独占 M（OS 线程）导致其他 goroutine 饿死，例如在纯计算循环中：
for i := 0; i < 1e9; i++ {
// heavy computation
if i%10000 == 0 {
runtime.Gosched() // 给调度器机会切换，避免卡住其他 goroutine
}
}
但更推荐的做法是把大任务拆成小块、用 channel 控制节奏，或直接用 context 做可取消的控制——Gosched 是低阶干预，多数业务逻辑无需手动调用。
goroutine 的实际并发行为高度依赖 GOMAXPROCS、系统线程数、调度器版本和 workload 特征，不要依赖 sleep 或 Gosched 做“精确”时序控制。
