Go slices.Concat 拼接多个切片时如何控制容量：空输入与别名边界

批量读取分页结果时，最容易被忽略的不是“能不能拼起来”，而是拼接结果是否还和某个输入切片共用底层数组。slices.Concat 从 Go 1.22 开始提供了一个清晰的答案：它按参数顺序复制元素，返回新切片；没有元素时返回 nil。容量是否刚好、空值是否需要保留，则要结合调用方的数据约定判断。

把 slices.Concat 当成“按顺序复制到新结果”的操作即可：输入切片不会被结果别名，空拼接结果是 nil；如果业务需要保留空但非 nil 的状态，要在调用后显式处理。

先看最小写法：分页结果按原顺序合并

例如三个批次分别来自数据库查询、缓存命中和补偿队列，业务希望保持批次顺序，可以直接传入多个 []Order：

package main

import (
    "fmt"
    "slices"
)

func main() {
    first := []string{"A-100", "A-101"}
    second := []string{"B-200"}
    merged := slices.Concat(first, second)
    fmt.Println(merged) // [A-100 A-101 B-200]
}

它不要求先创建一个容量足够的目标切片，也不会把空批次当成排序条件。要是批次顺序本身不可靠，应该先在业务层排序，不能指望 Concat 替你决定顺序。

实现为什么适合做一次性合并

官方实现的关键路径很短：先遍历每个输入计算总长度，再创建结果并逐段追加。下面的关系图对应源码中的真实节点。

它先执行 size += len(s)，然后调用 Grow[S](nil, size)，最后对每个输入执行 append(newslice, s...)，完成后 return newslice。因此，合并阶段不会修改输入切片的元素；容量细节由运行时分配策略决定，不应在业务代码里写死某个具体数字。

容量和空输入：两个容易混在一起的判断

空参数的返回值是 nil

empty := slices.Concat[[]int]()
fmt.Println(empty == nil) // true

allEmpty := slices.Concat([]int{}, []int(nil))
fmt.Println(allEmpty == nil) // true

如果下游把 nil 和空切片序列化成不同 JSON 结果，这个差异就是接口契约的一部分。需要“空数组”语义时，可以在边界处写成 if merged == nil { merged = []int{} }，别在每个调用点猜测。

总长度能控制复制次数，但不等于固定 cap

Concat 已经先计算所有输入的长度，避免一边遍历一边让结果反复扩容。源码还特意通过 Grow 让容量适配运行时 size class，并为少量后续 append 留出空间。所以测试应关注长度、内容和别名关系；除非你在做运行时专项基准，不要把 cap 当成稳定 API。

别名边界：结果是新底层数组

下面的测试用修改结果来观察边界，不依赖指针或运行时内部实现：

src := []int{10, 20}
got := slices.Concat(src)
got[0] = 99
fmt.Println(src) // [10 20]
fmt.Println(got) // [99 20]

这里的真实关系是“输入切片”经过复制进入“新底层数组”，再形成结果；修改结果不回写输入。空参数或全空参数则直接落到“空结果为 nil”。如果元素本身是指针或包含 map、slice 字段，Concat 只复制元素值，不会递归复制这些引用指向的对象。

什么时候不该用 Concat

如果数据来自一个持续产生的迭代器，或者需要边读边消费，Concat 需要所有输入切片已经存在，不能替代流式处理。若只是在循环中追加少量元素，直接维护一个目标切片更容易表达容量策略；若要保留自定义切片类型，确保各参数类型相同，因为泛型签名要求它们满足同一个 S ~[]E。

还有一个实际坑：不要把“合并后顺便去重”塞进 Concat。它只负责顺序拼接，去重、排序、过滤应当在单独步骤完成，这样出现数据异常时更容易定位。

相关问题

Concat 会修改第一个输入切片吗？

不会。它创建结果并复制每个输入的元素；但元素内部若持有引用，引用对象仍可能被多个切片共同指向。

空切片和 nil 切片拼接后如何返回空数组？

检查结果是否为 nil，在 API 输出边界显式替换为空切片，再交给 JSON 编码器。

能否依赖 Concat 的容量做性能优化？

可以把它视为一次性合并的合理实现，但不要依赖具体容量数字；需要稳定容量策略时，使用 make 加 append 并自行做基准。

小结

slices.Concat 解决的是“多个同类型切片按顺序得到一个独立结果”。它明确了复制边界，也明确了空结果的 nil 语义。把容量当实现细节、把空值当接口契约、把深层引用当另一个问题处理，代码会比围绕 cap 数字做猜测更稳。