为何Go中基于append实现的元组生成函数无法正确生成所有元组？

核心问题：切片底层数组复用导致元素覆盖 #

你的tuplesByAppend函数出错的根源在于Go语言append函数的底层数组复用机制：

当执行next := append(u, v)时，若原切片u的容量（cap）大于其长度（len），append会直接在u的底层数组剩余空间添加元素，不会创建新数组。在深度为4的循环中，前几层生成的切片容量刚好满足追加需求，导致多个next切片共享同一个底层数组。后续的append操作会修改这个共享数组，进而覆盖之前已经加入l2的元素。

而tuplesByPrepend中使用append([]T{v}, u...)时，每次都会先创建新切片[]T{v}，再复制u的元素进去，相当于每次都生成全新的底层数组，因此不会出现覆盖问题。

修复方案：强制创建独立切片 #

要修复tuplesByAppend，只需在追加元素前复制原切片，确保每次生成的next拥有独立的底层数组：

func tuplesByAppend[T any](list []T, depth int) [][]T {
    var l1 [][]T
    var l2 [][]T

    for _, v := range list {
        l1 = append(l1, []T{v})
    }

    for i := 1; i < depth; i++ {
        for _, u := range l1 {
            for _, v := range list {
                // 先复制原切片到新切片，再追加元素
                next := make([]T, len(u))
                copy(next, u)
                next = append(next, v)
                l2 = append(l2, next)
            }
        }
        l1 = l2
        l2 = [][]T{}
    }

    return l1
}

也可以用更简洁的写法替代复制步骤：

next := append([]T{}, u...) // 复制u到新切片
next = append(next, v)

为何其他深度看似正常？ #

不同深度下，切片的容量分配刚好避开了“复用底层数组”的场景。比如深度为3时，每次append可能触发了新数组分配；而深度为4时恰好遇到容量足够复用的情况，才暴露了问题。这个bug本质上一直存在，只是在特定条件下才显现。

内容的提问来源于stack exchange，提问作者Theodore Reimer