Go 1.27 泛型方法给集合 API 设计带来哪些变化

Go 1.27 的泛型方法变化，最适合用在集合转换这类“输入类型和输出类型都可能变化”的 API 上。过去只能把 Map 写成包级泛型函数；现在可以把它绑定到具体的 List[E] 上，并让结果类型由方法自己的类型参数 R 决定。需要先划清一条线：这不是泛型接口方法，接口方法集和接口分派规则没有因此改变。

先分清 Go 1.27 到底增加了什么

Go 1.18 已经支持泛型类型和泛型函数，却没有给普通具体类型的方法增加独立类型参数。于是集合库通常这样组织：接收者类型放在第一个参数，转换后的类型放在函数类型参数里。

// 包级函数需要把集合本身显式放进参数列表。
func MapBag[E any, R any](b Bag[E], fn func(E) R) Bag[R] {
    result := make([]R, 0, len(b.items)) // 预留容量，保持结果顺序。
    for _, item := range b.items {
        result = append(result, fn(item)) // 每个元素只经过一次转换。
    }
    return Bag[R]{items: result}
}

Go 1.27 的新增形式把 R 放到了方法上：func (Bag[E]) Map[R any](fn func(E) R) Bag[R]。其中 E 描述集合当前保存的元素，R 描述这次转换产生的元素。两者不是同一个类型参数，也不要求输入输出类型相同。

把集合转换操作收回类型边界

同一个 Bag 可以同时支持整数转文本、文本转长度等操作，调用方不必记住一串包级工具函数名称。下面的例子刻意让每一步改变元素类型，便于观察编译器推断出的结果：

// 具体类型的方法拥有自己的结果类型参数 R。
func (b Bag[E]) Map[R any](fn func(E) R) Bag[R] {
    result := make([]R, 0, len(b.items)) // 新集合不复用旧切片，避免类型不匹配。
    for _, item := range b.items {
        result = append(result, fn(item)) // 转换函数决定每个 R 的值。
    }
    return Bag[R]{items: result}
}

func example() {
    source := Bag[int]{items: []int{7, 12, 19}}
    names := source.Map(func(v int) string { // int -> string
        return fmt.Sprintf("item-%d", v)
    })
    sizes := names.Map(func(v string) int { // string -> int
        return len(v)
    })
    fmt.Println(sizes.items) // 结果仍是 Bag，只是元素类型已经变成 int。
}

这类写法的价值不只在少写几个字符。调用链从左到右描述数据如何变换，方法名称也和集合类型放在同一抽象边界内。若团队仍偏好函数式的嵌套形式，还可以使用方法表达式，把已实例化的方法转换为函数再传递；泛型方法和普通泛型函数一样，使用前必须完成显式或隐式实例化。

检查接口边界而不是只看调用语法

迁移时最容易误判的地方，是把“可以写 value.Map[T](fn)”理解成“类型因此拥有一个可供接口调用的泛型方法”。两者不是一回事。接口实现是类型的方法集与接口契约之间的关系，而不是某一次方法实例化后的偶然签名。

Go 1.27 允许具体类型声明类似 T.M[P any]() 的方法，但接口仍不能声明 M[P any]()。因此，具体方法可以服务于代码组织和直接调用，却不能凭一次 P 的实例化加入接口的方法集；跨包的接口分派也不会替调用方枚举所有可能的类型参数。

迁移集合 API 前做四项检查

1. 确认工具链。先用 Go 1.27 编译最小分支；旧版本不能把新方法语法当作兼容写法。
2. 确认接收者。把集合元素类型放在接收者的 E 中，把转换结果放在方法的 R 中，避免把两者硬合成一个参数。
3. 确认推断边界。让回调参数或返回值提供足够类型信息；复杂链条可用方法表达式或显式实例化拆开定位。
4. 确认接口契约。重新检查类型断言、mock 和跨包接口，不要因为直接调用成功就删除原有的泛型函数适配层。

如果集合库主要面向具体类型和链式转换，泛型方法能让 API 更集中；如果库的核心是跨包接口抽象，则应保留清晰的非泛型接口，并把需要两个独立类型参数的逻辑放在泛型函数或适配器中。这个取舍比单纯追求“方法写法更短”更重要。

常见问题

泛型方法会自动让接口支持任意结果类型吗？

不会。它只扩展具体类型的方法能力，接口方法仍必须遵守现有方法集规则。

集合的输入和输出类型必须相同吗？

不必。接收者可以是 Bag[E]，方法自己的 R 可以生成 Bag[R]，这正是 Map 类 API 的主要用途。

还需要保留包级 Map 函数吗？

不一定。直接面向集合对象时可迁移到方法；需要跨接口、函数组合或兼容旧工具包时，包级泛型函数仍然有价值。

官方说明见 Go Blog：Generic Methods。阅读发布说明时，重点应放在“具体泛型方法已经可用”和“泛型接口方法仍未开放”这两个同时成立的事实。