本文详解 Go 中模拟 Python yield 行为的 Channel 生成器实现原理，重点剖析因共享底层数组导致的竞态问题——当递归生成排列时未复制切片，会导致所有输出项指向同一内存地址，引发数据覆盖与结果重复。
本文详解 go 中模拟 python `yield` 行为的 channel 生成器实现原理，重点剖析因共享底层数组导致的竞态问题——当递归生成排列时未复制切片，会导致所有输出项指向同一内存地址，引发数据覆盖与结果重复。
在 Go 中，虽然没有 yield 关键字，但开发者常借助 goroutine + unbuffered channel 构建“逻辑上惰性、语义上类似生成器”的数据流。然而，这种模式并非 Python 生成器的直接平移——其底层并发模型决定了生产者与消费者并行执行，而非 Python 中严格的协程协作式调度。这正是本例中出现重复输出的根本原因。
? 问题本质：切片是引用类型，底层数组被反复复用
切片（[]int）本身是一个三元结构体：{ptr, len, cap}。它不包含数据，仅持有指向底层数组的指针。在 recurse 函数中，参数 A []int 始终指向同一块内存（原始切片的底层数组）。每次递归调用 swap 都在原地修改该数组内容；而当执行 c 并非数据副本。
由于 channel 是无缓冲的，c 仅同步了“发送动作完成”这一时刻，并不保证后续消费逻辑（如 fmt.Println(v)）执行时 v 所指的数据仍保持不变。更关键的是：一旦 c
✅ 正确做法：发送前显式复制数据
ra := make([]int, len(A)) copy(ra, A) // 深拷贝底层数组 c
此操作确保每个发送到 channel 的切片都拥有独立的数据副本，彻底消除竞态。
⚠️ 常见误区与陷阱总结
误区 1：“无缓冲 channel = 生产者必须等消费者处理完才继续”
→ 实际上，channel 同步的是发送/接收操作的完成，而非消费者对数据的使用完成。fmt.Println(v) 发生在接收之后，此时生产者早已推进至下一轮计算。误区 2：“只用值传递就能避免问题”
→ 切片本身是值类型（拷贝 ptr/len/cap），但 ptr 指向的底层数组仍是共享的。必须 copy() 或 append([]int(nil), A...) 显式复制元素。误区 3：“加 time.Sleep 能修复，说明只是时序问题”
→ Sleep 只是偶然延缓了竞态暴露，并未消除根本问题。真实环境中，调度延迟不可控，该 bug 必然重现。
✅ 推荐实践：安全生成器的四大原则
始终深拷贝可变数据
对于切片、map、struct 中含指针或切片字段等，发送前务必 copy 或构造新实例。关闭 channel 的责任明确
由唯一生产者 goroutine 在所有发送完成后调用 close(c)，避免消费者 range 永久阻塞。避免跨 goroutine 共享可变状态
如本例中，不应让递归函数与 channel 发送共享同一 []int。可考虑将 A 改为只读参数，或在每层递归中 make 新切片。考虑替代方案：迭代器风格（Next()）
若逻辑复杂或需精细控制生命周期，可放弃 channel，改用函数返回 (value T, ok bool) 的经典迭代器模式，完全规避 goroutine 泄漏与内存竞态风险。
// 示例：安全的排列迭代器（无 channel，无 goroutine）
type Permuter struct {
data []int
// ... 内部状态：当前索引、栈等
}
func (p *Permuter) Next() ([]int, bool) {
if !p.hasNext() {
return nil, false
}
perm := make([]int, len(p.data))
copy(perm, p.currentPerm()) // 每次返回新副本
p.advance()
return perm, true
}
Go 的生成器模式强大而灵活，但其并发本质要求开发者对内存模型与 goroutine 生命周期保持敬畏。理解切片的引用语义、channel 的同步边界，以及竞态发生的精确时机，是写出健壮生成器代码的基石。
