本文深入剖析 go 中使用 channel 实现“生成器（generator）”模式时，因未复制 slice 导致结果错乱的根本原因——本质是多个 goroutine 并发访问同一底层数组引发的数据竞态，而非 channel 同步机制失效。
本文深入剖析 go 中使用 channel 实现“生成器（generator）”模式时，因未复制 slice 导致结果错乱的根本原因——本质是多个 goroutine 并发访问同一底层数组引发的数据竞态，而非 channel 同步机制失效。
在 Go 中模拟 Python 的 yield 行为时，开发者常误以为：无缓冲 Channel 能保证“发送即冻结”——即 c <- A 后，A 的内容会被安全传递并“固化”，消费者读取时必然看到发送时刻的快照。但事实恰恰相反：Channel 传递的是 Slice 头部（指针、len、cap），而非底层数组副本。一旦发送完成，Goroutine 立即继续执行回溯逻辑（如 swap 和递归调用），反复修改同一底层数组，而消费者端仍在异步读取——这构成了典型的 数据竞态（data race）。
我们来看关键片段：
ra := make([]int, len(A)) copy(ra, A) // ✅ 正确：分配新底层数组，独立持有当前状态 c <- ra
若省略 copy，直接 c <- A，则所有发送的 []int 均指向同一内存地址（A.array）。如下图所示：
A (in recurse) ───┬──→ [1 2 3] ←─ 第1次发送后被修改为 [1 3 2]
├──→ [1 3 2] ←─ 第2次发送后被修改为 [2 1 3]
└──→ [2 1 3] ←─ …… 依此类推由于 yieldPermutations 在 Goroutine 中异步运行，且 recurse 是深度递归 + 原地交换，每个 c <- A 仅传递 Slice 头部引用，不阻塞数组修改。消费者 for v := range c2 读取时，v 实际指向的底层数组早已被后续递归步骤覆盖——因此输出出现大量重复或错位值（如 [1 3 2] 出现两次）。
? 验证竞态：在 c <- A 后插入 time.Sleep(100 * time.Millisecond)，输出将“看似正确”（实为时间掩蔽竞态），但这绝非解决方案——它既不可靠，也违背并发设计初衷。
正确实践：三类安全传递策略
| 方式 | 代码示例 | 适用场景 | 注意事项 |
|---|---|---|---|
| 显式复制（推荐） | ra := make([]int, len(A)); copy(ra, A); c <- ra | 所有需保留历史状态的生成器 | 开销可控，语义清晰，零竞态风险 |
| 只读封装（高级） | type Perm struct{ data [3]int }; c <- Perm{[3]int{A[0],A[1],A[2]}} | 固定长度、小数据量 | 利用数组值语义，避免指针共享 |
| 通道流式消费（最佳工程实践） | for v := range c { process(v) } 配合 defer close(c) | 生产者-消费者解耦 | 消费逻辑必须及时处理，避免堆积 |
⚠️ 关键认知纠正
❌ “无缓冲 Channel = 发送后立即暂停 Goroutine 直到消费完成”
✅ 实际行为：c <- A 仅阻塞至接收方准备好接收（即 v := <-c 执行到等待点），不阻止 Goroutine 继续执行后续代码（包括修改 A）。❌ “Slice 传递 = 数据拷贝”
✅ Slice 是轻量结构体（3字段）：{array *int, len int, cap int}。传递 Slice = 复制这三个字段，array 字段仍指向原内存。✅ 正确同步模型：Channel 保证控制流同步（goroutine 协作时机），不保证数据内存安全。对可变数据（如 slice、map）需显式隔离。
总结
该案例是 Go 并发编程中极具代表性的陷阱：混淆了通信同步与内存所有权。解决之道不在调整 Channel 缓冲区大小或加锁，而在于恪守一条黄金法则：任何通过 Channel 传递的可变数据结构（尤其是 slice），若其生命周期需跨越 Goroutine 执行边界，必须深拷贝或转为不可变形式。这既是 Go 内存模型的要求，也是编写健壮并发程序的基石。
