为切片算法编写保留具体类型的泛型函数

写 Go 泛型切片函数时，最容易忽略的不是元素类型，而是切片本身的具体类型。函数若写成 func Filter[E any]([]E, func(E) bool) []E，普通 []Order 没问题；但传入 type Orders []Order 后，推断出来的返回值仍是 []Order，新变量就不再拥有 Orders 上定义的方法。

解决办法是同时声明两个类型参数：S ~[]E 表示“底层类型为 []E 的具体切片类型”，E 表示元素类型；参数接收 S，结果也返回 S。这样调用方传入 Orders，返回类型就是 Orders；传入普通 []Order，返回类型仍是 []Order。

Go 泛型官方教程：https://go.dev/doc/tutorial/generics

触发信号：函数能调用，但结果的领域方法消失了

先看一个常见领域类型。团队用 Orders 表示订单集合，并给它定义了汇总方法：

package order

type Order struct {
	Amount int64
	Paid   bool
}

type Orders []Order

func (orders Orders) Total() int64 {
	// 汇总属于 Orders 的领域能力，不希望泛型函数调用后丢失。
	var total int64
	for _, item := range orders {
		total += item.Amount
	}
	return total
}

如果过滤函数只关心元素类型，写法通常是这样：

func FilterBasic[E any](in []E, keep func(E) bool) []E {
	// 返回值固定为未命名的 []E，因此不会保留调用方的命名切片类型。
	out := make([]E, 0, len(in))
	for _, item := range in {
		if keep(item) {
			out = append(out, item)
		}
	}
	return out
}

Orders 可以作为参数参与推断，因为它的底层类型是 []Order；但函数签名已经把结果写死为 []E。于是使用短变量声明接收结果时，静态类型是 []Order，不能直接调用 Total()。这就是本篇要处理的“类型退化”信号。

快速判断：问题出在元素类型还是切片类型

排查时先把两个维度分开：

只声明 E，算法就只能重建 []E。增加 S 后，编译器可以把调用点的完整切片类型绑定给 S。Go 语言规范给出的典型形式正是 [S ~[]E, E any]：S 受约束于所有底层类型为 []E 的类型。

~ 不是“可有可无的泛型装饰”。官方文章对这一点的解释很直接：S []E 只包含精确的未命名切片类型，而 S ~[]E 才包含底层类型为 []E 的命名类型。标准库 slices 中的 Clone、Delete、Compact 等函数也采用这一结构，并返回 S。

处理步骤：把过滤函数改成返回 S

保持具体切片类型的过滤函数可以这样写：

func Filter[S ~[]E, E any](in S, keep func(E) bool) S {
	// 显式保留 nil 输入，避免把 nil 变成非 nil 空切片。
	if in == nil {
		return nil
	}

	// make 的目标类型是 S，结果继续保留调用方的命名类型。
	out := make(S, 0, len(in))
	for _, item := range in {
		if keep(item) {
			out = append(out, item)
		}
	}
	return out
}

调用时通常不需要手写类型实参：

paid := Filter(orders, func(item Order) bool {
	// 谓词只决定元素是否保留，不改变元素类型。
	return item.Paid
})

total := paid.Total() // paid 的静态类型仍是 Orders。
_ = total

编译器先从实参 orders 推断 S 为 Orders，再由 Orders 的底层类型 []Order 推断 E 为 Order。调用等价于实例化一个参数接收 Orders、返回 Orders 的具体函数。

这里的关键不是强制类型转换。函数体从一开始就在 S 的类型空间里创建结果，编译器会持续检查 make、append 和返回值是否适用于约束中的所有类型。

告警确认：nil 与底层数组共享要单独约定

“返回类型还是 S”只解决静态类型保留，不等于函数的所有行为都自动正确。上线前至少要确认 nilness 与内存所有权。

是否保留 nil 输入

var orders Orders 是 nil 切片。如果直接 make(S, 0, len(in))，即使输入为 nil，结果也会变成非 nil 的空切片。很多业务不在意，但序列化、补丁语义或测试可能区分两者。上面的函数用显式分支保留 nil。

标准库 slices.Clone 文档会明确声明结果保留 nilness，这种写法值得借鉴：行为敏感时，不要让调用方靠读实现猜测。

是新分配还是原地过滤

上面的 make(S, 0, len(in)) 创建新的结果存储，修改输出元素不会覆盖输入元素。若为了减少分配改成 out := in[:0]，输出会复用输入底层数组；算法更省分配，但原切片可见内容可能被覆盖。两者都可以返回 S，却是完全不同的所有权契约。

func FilterInPlace[S ~[]E, E any](in S, keep func(E) bool) S {
	// 复用输入容量；调用方必须接受底层数组内容被覆盖。
	out := in[:0]
	for _, item := range in {
		if keep(item) {
			out = append(out, item)
		}
	}
	return out
}

如果函数名没有明显表达原地行为，就在文档中写清楚；不要把“保留类型”误写成“保留值和存储”。

告警边界：不是所有切片算法都应该返回 S

Filter、Clone、Delete 这类算法不改变元素类型，返回 S 合理。Map 若把 E 转换为另一个 R，结果的底层类型是 []R，已经不满足输入 S 的底层类型 []E，就不该强行返回 S。

func Map[S ~[]E, E any, R any](in S, convert func(E) R) []R {
	// 元素类型从 E 变为 R，因此返回新的 []R，而不是承诺保留 S。
	out := make([]R, len(in))
	for index, item := range in {
		out[index] = convert(item)
	}
	return out
}

如果调用方确实需要一个命名结果类型，例如 Amounts []int64，可以让调用方在边界处显式转换，或者设计一个接收构造器的更复杂 API。不要为了“看起来对称”而隐藏结果类型的真实变化。

回滚路径：签名过度泛化时怎么收回

泛型 API 的风险不是运行崩溃，而是约束承诺过宽，导致函数体难以维护。出现下面情况时，我会先回滚到更朴素的签名：

• 算法实际上只服务一种领域切片，复用收益很小；
• 不同命名切片需要不同的 nil、排序或内存所有权语义；
• 元素类型会变化，却试图用大量转换维持同一个 S；
• 调用方需要的不是切片形状，而是某个带方法的行为接口。

最保守的回滚是保留领域函数，例如 FilterPaid(Orders) Orders，等第二个真实类型出现后再抽取泛型内核。泛型应消除真实重复，而不是提前制造一个难懂的公共层。

复盘项：为泛型切片函数补齐测试矩阵

这类函数的测试不只看元素值。建议固定覆盖以下契约：

1. 普通切片：[]Order 能推断并返回 []Order。
2. 命名切片：Orders 返回后仍能调用 Total()。
3. nil 输入：根据函数文档确认结果应为 nil 还是非 nil 空切片。
4. 全部保留与全部删除：确认长度、容量策略和空结果语义。
5. 所有权：新分配版本修改输出不影响输入；原地版本明确允许覆盖。
6. 类型变化：Map 类函数返回 []R，不伪装成输入 S。

官方资料可继续参考：https://go.dev/ref/spec 中的类型参数、底层类型与类型推断章节，以及 https://pkg.go.dev/slices 中标准库切片函数的签名与行为说明。

常见问题

为什么不能只写 S []E？

因为不带 ~ 的类型项只匹配精确的 []E，不会把底层类型相同的命名切片纳入类型集合。要接收 type Orders []Order，应使用 S ~[]E。

返回 S 会自动保留切片上的所有方法吗？

返回值的静态类型保持为调用时推断出的 S，因此命名切片的方法集仍可用。但如果你先把结果赋给显式声明的 []E 变量，仍会在赋值边界丢掉命名类型。

什么时候只用 []E 更合适？

当 API 明确只承诺返回普通切片、调用方不依赖命名类型，或算法改变了元素类型时，[]E 或 []R 更简单。保留 S 是有意义的契约，不是所有泛型函数的默认模板。

S ~[]E 会带来运行时开销吗？

它首先是编译期类型约束和实例化机制，用来检查可接受的类型与函数体操作。真正的分配和复制开销取决于实现选择，例如 make 新切片还是复用 in[:0]，不能只从约束语法判断。

设计这类 API 时，最实用的判断只有一句：如果算法保持元素类型与切片形状，就让 S 记录调用方的具体切片类型，并把 S 原样返回；如果算法改变元素类型或所有权语义，就把变化写进签名和文档。这样泛型抽走的是重复循环，而不是领域类型携带的意义。