Go slices.Concat 如何合并多段切片：空输入、容量分配与原切片隔离

接口要把分页结果和补充结果合成一个列表时，最容易留下的不是语法问题，而是“合并后的切片到底还会不会改到输入”。Go 1.22 起可以用 slices.Concat 表达这个动作：它按参数顺序创建一个新切片；没有元素时返回 nil，不会把某个输入切片当成结果继续复用。

slices.Concat 适合合并多段同类型切片，但它的结果是一次新的复制；空合并得到 nil，如果接口必须输出 []，还要在边界处显式处理。

先看清 slices.Concat 解决的边界

过去合并三段切片通常要先估算总长度，再用 make 和 append 拷贝。这个写法没有错，但业务代码里经常出现一段输入漏算、扩容次数不明确，或者把结果继续绑定到某个原切片的问题。slices.Concat 把“按顺序拼接，并得到独立结果”收敛成一个调用。

package main

import (
    "fmt"
    "slices"
)

func main() {
    head := []string{"a", "b"}
    tail := []string{"c"}
    result := slices.Concat(head, tail)

    result[0] = "changed"
    fmt.Println(result) // [changed b c]
    fmt.Println(head)   // [a b]
}

这里的关键不是输出格式，而是写入 result[0] 后，head[0] 仍然是 a。这正是调用方需要的隔离关系。

参数顺序、类型推断和自定义切片

它的签名可以概括为 Concat[S ~[]E, E any](slices ...S) S。所有参数必须能归到同一个 S，元素类型 E 不要求可比较，因此字符串、结构体甚至接口切片都能使用。

type UserIDs []int

func mergeIDs(a, b UserIDs) UserIDs {
    return slices.Concat(a, b)
}

func main() {
    ids := mergeIDs(UserIDs{10, 11}, UserIDs{20})
    fmt.Println(ids) // [10 11 20]
}

参数位置不会被重新排序，也不会自动去重。若要去重、排序或按条件筛选，应把它们作为后续的独立步骤；不要把 Concat 当成集合运算。

空输入为什么得到 nil

官方文档明确规定，拼接结果为空时返回 nil。因此下面三种调用都不能用 reflect.DeepEqual 简单地当作同一个值理解：

var a []int
b := []int{}

fmt.Println(slices.Concat())       // []，实际值为 nil
fmt.Println(slices.Concat(a, b))   // []，实际值仍为 nil
fmt.Println(slices.Concat([]int{1})) // [1]

对 len、range 和 append 来说，nil 切片通常与空切片一样好用；但 JSON 编码时，nil 切片通常会成为 null，非 nil 空切片才会成为 []。如果接口契约要求数组形状，可以在返回前做一次归一化：

func concatForJSON(parts ...[]string) []string {
    result := slices.Concat(parts...)
    if result == nil {
        return []string{}
    }
    return result
}

结果切片如何完成隔离检查

不要只看打印结果来判断是否复制成功，最小检查应该同时覆盖顺序、长度和写入隔离。下面的断言把这三个状态放在一个可重复的测试里：

func TestConcatIsolation(t *testing.T) {
    left := []int{1, 2}
    right := []int{3, 4}
    got := slices.Concat(left, right)

    if !slices.Equal(got, []int{1, 2, 3, 4}) {
        t.Fatalf("unexpected result: %v", got)
    }
    got[0] = 99
    if left[0] != 1 {
        t.Fatalf("source slice was changed: %v", left)
    }
}

这个测试没有假设底层容量，也没有依赖指针地址；它只验证对调用方真正重要的行为：结果顺序正确，结果长度正确，修改结果不污染输入。

什么时候仍然用 append

如果你已经有一个明确的目标缓冲区，并且希望继续复用它的容量，append 仍然更直接。例如批处理循环里反复往同一个工作缓冲区写入，刻意复用容量可能比每轮都建立新结果更合适。slices.Concat 的语义则更清楚：把若干输入合成一个新的切片。

这里别急着用基准数字下结论。输入总长度、元素大小、调用频率和后续是否修改结果都会影响选择。一次性的列表合并优先看可读性；热路径则用基准测试验证分配和复制成本。

常见问题

slices.Concat 会去重吗？

不会。它只按参数顺序复制元素；去重需要额外的数据结构或筛选逻辑。

没有参数时能不能直接 range？

可以。nil 切片可以安全地 range，循环不会执行；如果要输出 JSON 数组，则应先转成非 nil 空切片。

两个输入切片会因为 Concat 共享底层数组吗？

结果是新的切片，修改结果元素不会改动输入。输入切片自身如果被其他代码修改，当然也不会反向更新已经生成的结果。

自定义切片类型能和 []int 混用吗？

不能直接混用，因为参数需要推断出同一个切片类型。可以先显式转换，或让所有参数都使用同一个自定义类型。

把选择落到接口返回值

如果调用方接受 null 和 [] 的差异，直接返回 slices.Concat 就够了；如果接口文档承诺始终返回数组，则在边界处把 nil 归一化。实际项目里，先写出这个契约，再决定使用 slices.Concat 或可控容量的 append，比只看代码长短更稳。