append是“追加”而非“拼接”，因其参数为可变参数...T而非[]T，正确用法为append(s1, s2...)；需预分配避免多次扩容，注意底层数组共享风险。
append 为什么不是“拼接”而是“追加”
很多人以为 append 是用来“拼接两个切片”的函数，结果写出 append(s1, s2) 直接报错：cannot use s2 (type []T) as type T in argument to append。这是因为 append 的第二个参数起是**可变参数（...T）**，不是 []T；它不接受另一个切片整体，除非你显式展开。
常见错误现象：直接传入另一个切片变量，没加 ...；或误以为 append 会自动扩容并复制底层数据，而忽略了底层数组可能被复用带来的副作用。
- 正确写法是
append(s1, s2...)—— 注意末尾的三个点 - 如果
s1容量足够，append复用底层数组，不分配新内存；否则会 realloc，性能跳变 - 若后续还会往结果切片里写，建议提前用
make([]T, 0, len(s1)+len(s2))预分配
预分配 + ... 展开才是真高效
高频拼接场景（比如日志聚合、协议打包）下，反复 append 小切片会导致多次扩容，时间复杂度退化成 O(n²)。真正省 CPU 的做法是：先算总长度，make 一次底层数组，再用 copy 或带 ... 的 append 填充。
使用场景：合并多个已知长度的切片，且最终结果要长期持有或传递给其他函数。
立即学习“go语言免费学习笔记（深入）”；
- 推荐模式：
dst := make([]byte, 0, len(a)+len(b)+len(c)); dst = append(dst, a...); dst = append(dst, b...); dst = append(dst, c...) - 比
append(append(a..., b...), c...)更清晰，也避免中间临时切片逃逸 - 如果只是临时组合传参（如
write(dst...)），不用赋值给变量，直接append(a..., b..., c...)即可
别忽略底层数组共享引发的意外修改
append 复用底层数组时，如果原切片和新切片共用同一段内存，改其中一个会影响另一个——这在并发或复用缓冲区时特别危险。
典型问题：从一个大缓存切片中 append 出小结果，之后又清空/重用缓存，导致小结果内容被覆盖。
- 检查是否真的需要共享底层数组：如果结果要长期保存，用
append(make([]T, 0, cap), src...)强制分离 - 或者用
copy手动控制：dst := make([]T, len(src)); copy(dst, src) - 对
[]byte尤其敏感，HTTP body、JSON 序列化后若还保留原始 buffer 引用，容易出脏数据
Go 1.22+ 的 slices.Concat 不等于 append 优化
Go 1.22 引入了 slices.Concat，看起来像“官方拼接函数”，但它内部就是用预分配 + copy 实现的，**不支持泛型约束以外的类型推导，也不处理容量复用逻辑**。
性能上它和手写预分配 + copy 差不多，但语义更明确；不过它不会帮你规避底层数组共享问题，也不会自动选最优策略（比如是否该用 append 还是 copy）。
- 适合快速原型或代码可读性优先的场景：
slices.Concat(a, b, c) - 不适合对延迟敏感或需精确控制内存布局的场景（如网络包组装）
- 它不接受
nil切片，而append(s, nil...)是合法且无操作的——这点容易踩坑
真正难的不是怎么写快，是怎么判断“此刻该不该复用”“谁还在引用这块内存”“预分配长度有没有算错”。这些没法靠函数封装掉，得看上下文。
