Go中append并非总是创建新底层数组——当容量足够时，它会复用原底层数组并覆写后续内存，导致递归中多个切片共享同一数组片段，引发意外数据污染。
go中`append`并非总是创建新底层数组——当容量足够时，它会复用原底层数组并覆写后续内存，导致递归中多个切片共享同一数组片段，引发意外数据污染。
在Go语言中，append函数的行为与Python的list.append()或字符串拼接（如+）存在本质差异：append是值语义下的“智能扩容”操作，而非无条件拷贝。这一特性在递归场景（如全排列生成）中极易引发隐蔽bug，正如问题中所示——permutation输出大量重复的[3 3 3]，而perms却能正确输出全部6种字符串排列。
? 根本原因：append的底层数组复用机制
切片（[]int）由三部分组成：指向底层数组的指针（Data）、长度（Len）和容量（Cap）。append在追加元素时遵循以下规则：
- 若 len(s) + N ≤ cap(s)：直接在现有底层数组末尾写入，不分配新内存，且可能覆写原数组中len(s)之后的原有数据；
- 否则：分配新底层数组，拷贝原数据，再追加。
在原始permutation函数中：
permutation(
append(prefix, str[i]), // ✅ 安全：prefix通常较短，但即使扩容也不影响str
append(str[0:i], str[i+1:]...), // ❌ 危险！str[0:i]的cap往往 ≥ i + (n-i-1) = n-1，
// 导致append直接覆写str[i:]区域
)
以 str = []int{1,2,3} 为例（假设底层数组容量为3）：
- i=0 时：str[0:0] 是空切片，cap=3，append(..., str[1:]...) → 将[2,3]写入str[0:]，结果变为[2,3,3]
- 后续递归中，str 已被污染，所有分支均基于错误状态继续计算
这就是为何输出中出现多个 [3 3 3] —— 底层数组被反复覆写，最终全部元素被覆盖为最后一个值。
✅ 正确解法：强制深拷贝，切断共享引用
避免复用的关键是确保每次append都作用于一个独立、容量精确的新切片。推荐做法：
func permutation(prefix, str []int) {
n := len(str)
if n == 0 {
fmt.Println(prefix)
} else {
for i := 0; i <blockquote><p>? <strong>为什么make([]int, 0, n-1)有效？</strong><br>make创建的切片拥有独立底层数组（即使长度为0），其cap = n-1，后续append必然在该专属数组上操作，彻底隔离污染。</p></blockquote><h3>⚠️ 补充注意事项</h3>
prefix为何相对安全？
append(prefix, str[i]) 通常不会污染str，因为prefix和str一般指向不同底层数组。但若prefix恰好是str的子切片（如prefix = str[:0]），同样会触发覆写——因此永远不要假设切片间相互独立。性能权衡：
每次make分配内存会带来轻微开销，但在递归深度可控（如排列长度≤12）时，可读性与正确性远高于微优化。若需极致性能，可预分配池化切片，但须严格管理生命周期。调试技巧：
使用fmt.Printf("str=%v, cap=%d, ptr=%p\n", str, cap(str), &str[0])打印关键切片的容量与地址，快速定位共享点。
? 总结
| 行为 | 字符串 s1 + s2 | 切片 append(s, x...) |
|---|---|---|
| 内存语义 | 总是新建字符串（不可变） | 容量足够时复用底层数组（可变） |
| 是否影响原数据 | 否 | 可能覆写原底层数组后续内容 |
| 递归安全建议 | 天然安全 | 必须显式make或copy隔离 |
牢记：在递归、并发或多处共享切片的场景中，append不是“纯函数”，而是带有副作用的内存操作器。 唯一可靠的防御策略，是主动放弃隐式复用，拥抱显式控制——用make声明意图，用copy保证隔离。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
