Go中goroutine启动后不阻塞主函数，主函数退出则所有goroutine强制终止；需用sync.WaitGroup等待或time.Sleep临时观察，且循环中传参避免闭包陷阱；channel使用不当易致泄漏或死锁。
goroutine 启动后不等待，主函数退出就结束
Go 的 goroutine 是轻量级线程，但启动后默认不阻塞主流程。如果主函数执行完直接退出，所有未完成的 goroutine 会被强制终止，看不到输出。
- 用
time.Sleep()临时观察效果（仅测试用，不可用于生产） - 更可靠的方式是用
sync.WaitGroup等待所有任务完成 - 避免在循环中直接启动
goroutine并传入循环变量——容易捕获到变量最终值，需显式传参或用局部变量捕获
package main
<p>import (
"fmt"
"sync"
"time"
)</p><p>func main() {
var wg sync.WaitGroup</p><pre class='brush:php;toolbar:false;'>for i := 0; i < 3; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
fmt.Printf("goroutine %d running\n", id)
time.Sleep(time.Second)
}(i) // 注意：这里把 i 作为参数传入，避免闭包陷阱
}
wg.Wait() // 主 goroutine 阻塞等待全部完成
fmt.Println("all done")}
goroutine 泄漏：忘记关闭 channel 或未消费完数据
当用 channel 配合 goroutine 做生产者-消费者模型时，若发送端关闭了 channel，但接收端没处理完或没检测关闭状态，可能造成接收 goroutine 永久阻塞；反之，若接收端已退出而发送端还在往无缓冲 channel 写，也会死锁。
- 使用
for range ch自动处理 channel 关闭 - 带缓冲的 channel 能缓解压力，但不能替代逻辑控制
- 超时控制推荐用
select+time.After()，避免无限等待
go func(ch chan int) {
for i := 0; i < 5; i++ {
select {
case ch <- i:
case <-time.After(time.Second):
fmt.Println("send timeout, skip")
}
}
close(ch)
}(ch)大量 goroutine 启动导致内存或调度压力
每个 goroutine 初始栈约 2KB，虽轻量，但百万级并发仍会耗尽内存；同时 Go 调度器不是为“越多越好”设计的，过度创建反而降低吞吐。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.GOMAXPROCS(n)控制并行数（通常保持默认即可） - 对 I/O 密集型任务，优先用 channel + worker pool 模式限制并发数，而非为每个请求启一个 goroutine
- 可通过
runtime.NumGoroutine()监控当前数量，排查泄漏
goroutine 中 panic 不会传播到主 goroutine
每个 goroutine 独立运行，其中的 panic 默认只终止自身，不会中断主流程，也容易被忽略。
- 用
recover()在 goroutine 内部捕获 panic（必须在 defer 中调用） - 不要依赖外部监控捕获 goroutine panic——它根本不会冒泡出去
- 日志中需明确标注 panic 来自哪个 goroutine，例如打上 ID 或上下文
go func(id int) {
defer func() {
if r := recover(); r != nil {
fmt.Printf("goroutine %d panicked: %v\n", id, r)
}
}()
panic("something went wrong")
}(1)实际写并发逻辑时，最常被忽略的是「等待机制」和「错误隔离」——前者导致程序提前退出、结果丢失，后者导致 panic 静默失败、问题难以复现。
