扩容时底层数组必然发生完整浅拷贝，运行时调用growslice分配新数组、逐字节复制原数据、再写入新元素；copy仅复制值或指针，不递归处理引用类型，深拷贝需手动实现。
扩容时底层数组必然发生完整拷贝，且是浅拷贝 —— 这不是可选项，而是 Go 运行时的强制行为。
append 触发扩容时，旧数据怎么搬过去？
只要 len(s) == cap(s) 且调用 append，运行时就会调用 growslice 函数，执行三步：分配新数组 → 逐字节复制原数据 → 在新数组末尾写入新元素。
这个复制过程不区分元素类型：对 []int 是整数拷贝，对 []*string 是指针值拷贝（即新数组里存的仍是原字符串的地址），对 []struct{ name string } 是结构体字段逐字段拷贝（name 字段里的字符串头仍指向原底层字节数组）。
常见错误现象：
- 误以为
append扩容后还能通过旧切片访问“刚被覆盖”的位置（实际旧底层数组未被修改，但新切片已完全脱离它） - 在并发场景中，一边
append扩容、一边读旧切片，结果读到的是旧数组的 stale 数据（二者已无关联）
为什么 copy 是浅拷贝？有没有深拷贝方案？
Go 没有内置深拷贝机制，因为语言不追踪引用关系。所谓“深拷贝”必须由开发者按业务语义定义。
copy 函数只做内存块复制，它不知道 *T 指向哪里、map 里存了什么、channel 是否活跃。所以：
- 对
[]*int：copy 后两个切片的指针仍指向同一堆内存 - 对
[]string：每个string的 header（ptr+len+cap）被复制，但底层字节数组仍共享 - 对
[]struct{ data []byte }：struct 被复制，但每个data字段仍指向原底层数组
若需深拷贝，必须手动遍历 + 分配 + 复制子结构，例如：
for i := range src {
dst[i] = make([]byte, len(src[i]))
copy(dst[i], src[i])
}
扩容策略如何影响拷贝开销？
拷贝成本 = 原切片长度 × 元素大小。扩容策略决定你多久触发一次拷贝，以及每次拷贝多少数据。
关键点：
- 容量 cap =
old cap * 2→ 拷贝量翻倍，但摊还后均摊 O(1) - 容量 ≥ 1024：新
cap≈old cap * 1.25→ 单次拷贝增长变缓，适合大 slice - 无论哪种，最终容量都会向上对齐到内存页边界（如 8 字节对齐），所以
cap值可能比理论值略大
性能陷阱：
- 频繁从
make([]T, 0)开始 append：第一次就拷贝 0 字节，第二次拷贝 1×size，第三次拷贝 2×size……总拷贝量达 O(n²) - 预估不足，比如知道要存 1000 个元素却只
make([]int, 0, 10)：会触发约 7 次扩容，拷贝总量超 2000 个 int
什么时候根本不会发生拷贝？
只有两种情况不触发底层数组拷贝：
len 时调用 <code>append：直接写入原数组，仅更新len- 用三参数切片表达式收紧容量，再
append：例如s[2:4:4]后append必然扩容，但这是你主动放弃复用，而非避免拷贝
注意：copy(dst, src) 本身也会触发 dst 的底层数组分配（如果 dst 是 nil 或 cap 不足），但它不等价于 append —— 它不改变 dst 长度，也不自动扩容。
最易被忽略的一点：哪怕你只追加一个元素，只要触发扩容，整个原底层数组都会被完整复制。这不是优化点，而是设计契约 —— Go 保证 append 返回的新切片与旧切片彻底隔离，但也意味着你永远无法绕过这次拷贝。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
