泛型函数何时比接口更合适，判断标准是数据还是行为

我在把几组相似的 Go 工具函数合并时，最容易犯的错不是泛型语法写错，而是把“类型不同”误判成“行为可以替换”。判断标准可以先记成一句话：同一套算法只是要适配多种类型，用泛型；不同类型需要各自实现行为，用接口。如果调用方只需要调用某个方法，例如读取数据，那么接口通常更直接。

先看复用的是数据，还是行为

泛型函数的核心价值是把一套算法写一次，再把类型差异交给类型参数。例如排序、映射、查找、比较这类逻辑，对不同元素类型往往仍然是同一套步骤；此时类型参数能让切片元素和返回值保持关联，调用方也能在编译期发现不匹配。

接口解决的是另一类问题：调用方不想知道对象的具体类型，只要它提供某组方法。文件、网络连接和内存缓冲区的读取实现并不相同，但上层只需要 Read 行为。把这类差异硬塞进泛型，反而会让签名变长。

泛型函数要保留什么类型关系

先写算法，再提取真正变化的类型，不要一开始就设计复杂约束。下面这个函数对任何元素类型执行同一转换，T 和 R 分别保留输入与输出的类型信息：

// Map 对每个输入元素执行同一转换，返回与转换结果匹配的新切片。
func Map[T any, R any](in []T, convert func(T) R) []R {
	// 预分配结果空间，避免转换过程中反复扩容。
	out := make([]R, 0, len(in))
	for _, item := range in {
		// 转换规则由调用方提供，但遍历算法只有一份。
		out = append(out, convert(item))
	}
	return out
}

这里的重点不是少写了一个函数，而是 API 明确表达了“输入元素经过转换得到另一种元素”。如果算法需要比较、相加或排序，就把约束收窄到实际操作所需的集合；如果函数只保存或搬运值，any 反而更诚实。

方法实现不同，就让接口承担替换

当同一个方法在不同类型上有不同实现时，接口更合适。以读取为例，文件读取可能等待磁盘，网络读取可能等待连接，内存读取则只是移动指针；它们共享的是调用约定，不是内部算法：

// ReadPreview 只依赖读取行为，不要求调用方暴露具体类型。
func ReadPreview(r io.Reader, limit int) ([]byte, error) {
	// limit 是业务上限，避免预览接口无限制读取输入。
	buf := make([]byte, limit)
	n, err := r.Read(buf)
	if err != nil && err != io.EOF {
		// 保留底层错误，便于上层区分超时、连接断开等情况。
		return nil, err
	}
	return buf[:n], nil
}

这个签名的好处是调用方可以传入任何满足 io.Reader 的值。若改成 func ReadPreview[T io.Reader](r T, ...)，并没有获得新的行为，只是增加了一个不必要的类型参数。Go 官方关于泛型使用时机的建议也把“只需要调用方法”归入接口场景。

四项检查帮你做最后选择

还要单独排除一个误区：不要只因为泛型看起来更“新”，就认为它一定更快。选择应由类型关系和行为边界决定；若确实需要运行时接收未知类型、处理异构数据，而且每种类型的逻辑又不同，接口或反射可能比泛型更符合问题。

常见问题

泛型函数是不是一定比接口性能好？

不能这样推断。泛型首先解决复用和类型关系问题，不能仅凭语法判断性能；应该用实际数据、调用路径和基准测试做决定。

一个函数既能用泛型又能用接口怎么办？

优先看调用者需要什么。如果需要让输入类型和输出类型保持可推断的联系，用泛型；如果只需要调用一组方法并允许不同实现接入，用接口。

类型约束应该写得多复杂？

从函数实际执行的操作出发，使用能表达这些操作的最小约束。过宽会限制实现，过窄则会把无关的类型细节暴露给调用方。

实际重构时可以先保留原来的接口或普通函数，找到重复算法和稳定的输入输出关系后再引入类型参数。这样做通常比先搭一套复杂约束，更容易判断泛型到底减少了重复，还是只增加了阅读成本。