append合并两个切片时底层数组是否复用取决于目标切片剩余容量（cap-len）是否≥源切片长度；够则复用底层数组，不够则分配新数组并完全解耦。
append 合并两个切片时，底层数组是否复用？
取决于目标切片的剩余容量（cap - len）是否 ≥ 源切片长度。不是看“谁长谁短”，而是看“够不够装”。
常见错误现象：dst = append(dst, src...) 后发现修改 dst 影响了原 src，或反之——这说明它们意外共享了底层数组。
- 如果
cap(dst) >= len(dst) + len(src)，append直接在dst底层数组末尾拷贝src元素，不分配新数组 - 否则，
append分配新数组，复制dst全部元素 +src全部元素，dst和src完全解耦 - 注意：
src本身是否为nil或小容量切片不影响判断逻辑，只影响其自身len和cap
为什么用 append(dst, src...) 后 dst 的 cap 可能远大于 len(dst)？
因为扩容策略按当前总长度分段计算，不是简单翻倍。Go 不保证新容量等于 len(dst)+len(src)，只保证 ≥ 这个值。
使用场景：批量合并日志条目、拼接协议帧、构建 HTTP 响应体等对内存局部性有要求的操作。
立即学习“go语言免费学习笔记（深入）”；
- 例如
dst当前len=100,cap=128，要追加len=10的src→ 新cap很可能仍是128（够用，不扩容） - 若
dst当前len=120,cap=128，追加len=10的src→ 触发扩容，新cap可能是256（而非130） - 不同 Go 版本对小切片（
len ）和大切片（≥1024）的扩容步长不同，但都遵循“单调递增、不缩容”原则
如何避免 append 合并时意外共享底层数组？
当必须确保结果切片与输入完全隔离（比如传递给不可信第三方、做 deep copy 前置步骤），不能依赖容量是否充足这个不确定条件。
实操建议：
- 显式预分配：用
make([]T, len(dst)+len(src))创建新切片，再用copy拆分填充，完全可控 - 强制解耦：先
dst = append(dst[:0], dst...)截断并重切（触发一次小扩容），再append(dst, src...)，利用扩容必然新建数组的特性 - 直接用
append(append(make([]T, 0, len(dst)+len(src)), dst...), src...)—— 虽啰嗦，但语义清晰且强制预分配
append 合并 nil 切片是否安全？
完全安全，且是推荐写法。Go 运行时把 nil 当作长度 0、容量 0 的合法切片处理。
性能影响：首次 append 会触发最小块分配（通常 1–2 个元素起步），后续增长才进入标准扩容路径。
-
var a []int是nil；append(a, 1, 2, 3)等价于make([]int, 3, 3)（具体初始 cap 取决于元素类型和运行时版本） - 不要写
a = append(a, x); if a == nil { ... }——append永远返回非-nil 切片 - 多个
nil切片合并：append(nil, a..., b..., c...)是惯用初始化模式，底层只分配一次
真正容易被忽略的是：合并后若继续在结果切片上反复 append，其后续扩容行为完全由新切片的当前 len 和 cap 决定，和原始 dst、src 再无关系——这点在调试内存泄漏或数据污染时最关键。
