goroutine 并非天然并发安全，需用 sync.WaitGroup 显式等待、sync.Mutex 或 channel 协调共享数据，避免竞态和泄漏；启用 -race 检测数据竞争，遵循“通过通信共享内存”原则。
Go 语言的 goroutine 不是“开了就能并发安全”的魔法，它只是轻量级线程的调度单元；真正决定是否并发正确、是否高效，取决于你如何协调它们——尤其是共享数据时用不用 sync.Mutex、sync.WaitGroup 或 channel。
goroutine 启动后不等它结束，主程序就退出了
这是新手最常遇到的“goroutine 没执行就没了”。根本原因是 Go 运行时不会自动等待未完成的 goroutine，main 函数返回即进程终止。
- 用
sync.WaitGroup显式等待：在启动前wg.Add(1)，每个goroutine结束前调用wg.Done()，最后wg.Wait() - 别用
time.Sleep“凑数”——它不可靠，容易过长或过短，且掩盖了同步逻辑缺失的问题 -
WaitGroup的Add必须在go语句之前调用，否则可能Done先于Add导致 panic
多个 goroutine 读写同一变量导致数据竞争
只要两个及以上 goroutine 同时访问同一变量，且其中至少一个是写操作，又没做同步，Go 的 race detector 就会报 Data race。这不是偶尔出错，而是必然未定义行为。
- 简单场景（如计数器）优先用
sync/atomic：比如atomic.AddInt64(&counter, 1)，比加锁更轻量 - 复杂逻辑（如更新结构体多个字段）必须用
sync.Mutex或sync.RWMutex，注意Lock/Unlock成对，且锁粒度别过大 - 启用竞态检测：编译运行时加
-race参数，go run -race main.go，别等上线才暴露问题
用 channel 替代共享内存来传递结果
不是所有共享都该加锁；Go 推崇“不要通过共享内存来通信，而应通过通信来共享内存”。channel 是实现这一理念的原生机制。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 启动
goroutine时传入一个chan类型参数，让其执行完把结果send进去，主协程从chan中receive - 记得关闭
channel（通常由发送方关），否则接收方可能阻塞；或用range遍历带缓冲的chan - 缓冲通道（
make(chan int, 10)）能解耦发送和接收节奏，但别盲目设大缓冲——它会掩盖背压问题，还占用内存
goroutine 泄漏：忘了取 channel 数据或没处理关闭信号
一个长期运行却无人接收的 goroutine 会一直占着栈内存和调度资源，数量多了直接 OOM。常见于监听 channel 却没考虑退出路径。
- 永远不要无条件
for { select { case x := ，除非你能确保 <code>ch一定会被关闭且接收方存在 - 配合
context.Context控制生命周期：select中加入case ，并在上层调用 <code>ctx.Cancel() - 启动大量短期
goroutine（如 HTTP handler）时，避免闭包捕获外部变量导致意外引用，引发内存无法释放
并发不是开越多 goroutine 越快，而是让每个都做该做的事、及时结束、不抢资源。实际项目里，channel 和 context 的组合往往比裸用 go + sync 更易维护，也更贴近 Go 的设计直觉。
