泛型工具函数出错多因类型约束不匹配而非语法错误：Max需Ordered约束（Go 1.21+内置），Map用any可透传但不可访问字段，Keys要求key满足comparable，Filter推导失败时需显式指定类型参数。
泛型工具函数写不对，八成是约束没配对，不是语法错，而是契约没说清。
func Max[T constraints.Ordered](a, b T) T 编译失败？检查约束是否导入
Go 1.21+ 已将 constraints.Ordered 移入标准库，无需再导入 golang.org/x/exp/constraints。但如果你用的是旧版（undefined: constraints.Ordered。
- Go 1.21+ 正确写法：
import "constraints"，然后直接用[T constraints.Ordered] - Go 1.18–1.20 必须：
import "golang.org/x/exp/constraints"，且注意该包仍属 experimental，不能用于生产环境的强依赖 - 别手写
type Ordered interface{ ~int | ~float64 }来“绕过”——它漏了string、int32等合法类型，也不含比较运算符语义，a > b仍会编译失败 - 如果只是需要 == 和 !=，用
[T comparable]即可，但它不支持>，所以Max必须用Ordered
func Map[T, U any](s []T, f func(T) U) []U 怎么让 T 支持自定义类型？
问题不在 Map 函数本身，而在于调用时传入的切片类型是否满足其参数约束。[T any] 允许任意类型，但若你传入 []MyStruct，而 MyStruct 是自定义类型（如 type MyStruct struct{ X int }），它天然满足 any，不会报错。
- 真正卡住的点是：函数体里若对
T做了操作（比如v.X），那就超出any能力范围——必须换约束，例如[T interface{ X() int }] - 若想让
Map同时支持int和MyStruct，又不想改调用方代码，就别在函数内访问字段；保持纯透传，any就够用 - 性能提示：
[T any]的Map在编译期生成具体版本（如Map[int, string]），比用[]interface{}+ 反射快得多，也无逃逸 - 注意：不能写
Map(s, func(v T) U { ... })并指望编译器从闭包推导T——闭包类型不参与泛型推导，必须靠s的类型来定；若s是nil，就得显式写Map[int, string](nil, ...)
func Keys[K comparable, V any](m map[K]V) []K 怎么处理 K 是 struct 或指针？
comparable 约束看似宽松，实则严格：它只允许能用 == 比较的类型。struct 可以，但前提是所有字段都 comparable；指针可以，但 *MyStruct 要求 MyStruct 本身可比较。
立即学习“go语言免费学习笔记（深入）”；
- 合法：
type User struct{ ID int; Name string }→map[User]int可用Keys - 非法：
type Bad struct{ Data []byte }→[]byte不可比较，整个 struct 不满足comparable，编译报错 - 指针场景：
map[*User]int是合法的，因为指针类型天然comparable；但*Bad仍非法，因底层类型不满足约束 - 若你硬要支持不可比较的 key（比如含切片的 struct），
Keys就不该用泛型——改用func Keys(m interface{}) []interface{}+ 反射，但代价是失去类型安全和性能
func Filter[T any](s []T, f func(T) bool) []T 显式指定类型参数的时机
类型推导在 Filter 这类单切片+函数的场景中很稳，但以下情况必须手动标注：
- 输入是
nil：Filter(nil, f)无法推出T，得写成Filter[int](nil, f) - 切片变量是
interface{}类型：var s interface{} = []string{"a", "b"}; Filter(s.([]string), f)不行，因为s.([]string)是运行时断言；正确做法是避免这种赋值，或直接用Filter[string](s.([]string), f) - 函数参数本身是泛型，且上下文模糊：
func Wrap[T any](s []T) []T { return Filter(s, isEven) }中，若isEven是func(int) bool，编译器无法反推T是int，必须写Filter[int](s, isEven) - 错误信息常不指向调用行，而指向泛型函数定义处——遇到推导失败，先看实参有没有类型歧义，而不是改函数签名
泛型工具函数最易被忽略的点：它不是写一次就完事，而是每次调用都在生成新函数实例。如果泛型参数组合爆炸（比如 Map[string, *User]、Map[int64, []byte] 大量并存），二进制体积和编译时间会明显上升——这不是 bug，是单态化的代价。
