Go协程通信应避免共享内存，通过channel显式传递数据；局部变量天然隔离，需防止闭包捕获、返回局部指针或共享切片底层数组；channel是点对点管道，须由发送方关闭，接收方用v, ok :=安全读取。
Go 模块内协程通信不需要「数据隔离」——因为 Go 本来就**不鼓励共享内存**，而要求你用 channel 显式传递数据。所谓“隔离”，其实是避免多个 goroutine 同时读写同一份堆上变量（如全局 map、struct 字段），否则必踩竞态。真正要做的，是把「谁拥有数据」和「谁负责关闭通道」理清楚。
goroutine 局部变量天然隔离，别逃逸到堆上
每个 goroutine 的栈上变量（比如函数内声明的 counter、result）自动隔离，无需任何同步。问题出在「本该局部，却意外变成共享」：
- 闭包捕获外部变量（如
for i := range items { go func() { use(i) }() }）→ 所有 goroutine 共享同一个i变量 → 最终全用最后一次循环值 - 返回局部变量的指针（如
return &localStruct）→ 编译器会将其分配到堆 → 多个 goroutine 拿到同一地址 → 竞态风险 - 把切片或 map 传给 goroutine 而不拷贝（
go process(dataSlice)）→ 底层dataSlice的array指针被共享 → 并发修改底层数组
解决方法很简单：显式传参、显式拷贝、用 := 绑定循环变量。例如：
for i := range items {
i := i // 重绑定，确保每个 goroutine 拥有独立副本
go func() {
fmt.Println(items[i]) // 安全
}()
}
channel 是唯一推荐的数据传递通道，不是共享池
channel 不是「让多个 goroutine 去里面抢数据」的容器；它是「点对点交付」的管道。常见误用包括：
立即学习“go语言免费学习笔记（深入）”；
- 多个 goroutine 同时从一个无缓冲
chan int接收 → 只有一个能抢到，其余永久阻塞（除非有select+default） - 一个 goroutine 发送，但没关 channel，另一个用
for range ch死等 →all goroutines are asleep - deadlock! - 在接收方调用
close(ch)→ panic，因为只有发送方能关
正确姿势：发送方控制生命周期，接收方用 v, ok := 判断是否关闭，或用 <code>for v := range ch 自动退出。例如：
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
ch := make(chan string)
go func() {
ch <- "hello"
close(ch) // ✅ 发送完立刻关
}()
for msg := range ch { // ✅ 自动在 close 后退出
fmt.Println(msg)
}
多生产者场景下必须用 sync.WaitGroup 控制关闭时机
当多个 goroutine 往同一个 channel 发数据（扇入），不能靠某个 goroutine 自己决定关 channel —— 它关早了，其他 goroutine 还没发完，就会 panic；关晚了，接收方永远等不到 close。
必须用 sync.WaitGroup 协调所有发送者完成后再统一关：
- 启动前
wg.Add(n)，每个发送 goroutine 结束时wg.Done() - 另起一个 goroutine 等
wg.Wait()，然后close(ch) - 接收方仍用
for range ch，安全退出
这是最容易被跳过的一步，也是死锁高发区。
不要用全局变量模拟「模块级状态」
有人为图方便，在包级定义 var cache = make(map[string]int)，再用 sync.RWMutex 包裹读写。这看似“隔离了访问”，实则埋下三颗雷：
- 模块内任意函数都能改它 → 调用链越深，越难追踪谁在什么时候改了什么
- 测试时无法重置 → 一个测试跑挂，后续全受影响
- 并发压测下锁争用严重 →
RWMutex在高写场景下性能远不如「每个 goroutine 拥有自己的 map + 最后 merge」
替代方案更轻量：把状态封装进结构体，用构造函数初始化，通过方法暴露受控操作。channel 配合结构体字段，比全局变量 + 锁更清晰、更易测、更符合 Go 哲学。
最常被忽略的一点：channel 的所有权转移是隐式的，但必须明确。谁创建、谁关闭、谁接收——这三个角色一旦混淆，死锁或 panic 就只是时间问题。写 goroutine 时，先画两笔：左边写「我往哪发」，右边写「谁在等我发完」，再动手敲代码。
