泛型约束错误会导致编译失败，必须用方法集或预定义约束（如comparable、~int），不可写字段；~int兼容类型别名，而int不兼容；类型推导失败需显式指定类型；约束应遵循最小必要原则。
泛型约束写错会直接编译失败，不是运行时报错
Go 的泛型约束在编译期强制校验，type T interface{} 这种空接口写法虽然合法，但等于放弃类型安全；真正要用约束，必须明确列出方法集或使用预定义约束。常见错误是把结构体字段当约束条件写，比如 type T interface{ Name string } —— 这是非法的，Go 不允许在 interface 中声明字段，只允许方法签名。
实操建议：
- 用
comparable约束需要 == 或 != 比较的类型（如map[K]V的键） - 自定义约束优先用 interface 声明方法，例如
type Number interface{ ~int | ~float64 }，其中~表示底层类型匹配 - 别在约束里写具体值或字段，只写方法或类型集合
- 如果要约束多个行为，用嵌套 interface 组合：
type ReadWriter interface{ io.Reader; io.Writer }
~int 和 int 在约束里区别很大
~int 表示“底层类型为 int 的所有类型”，包括 type MyInt int 这类自定义别名；而 int 只匹配 int 本身。实际项目中，用户常定义自己的整数类型（比如带单位的 type Milliseconds int），如果约束写成 int，这类类型就无法传入泛型函数。
实操建议：
- 需要兼容别名类型时，一律用
~int、~string等形式 -
~只能用于基本类型（int,float64,string,bool,uintptr等），不能用于 struct 或 interface - 数组、切片、map 等复合类型不支持
~，只能用具体类型或 interface 方法约束
泛型函数调用时类型推导失败的典型场景
Go 编译器有时无法从参数自动推导泛型类型，尤其当参数是 nil、未显式类型化的字面量，或多个参数类型不一致时。例如 func Max[T constraints.Ordered](a, b T) T，调用 Max(1, 3.14) 会报错，因为 1 是 int，3.14 是 float64，没有共同的 T。
实操建议：
- 避免混合字面量类型，统一显式转换：
Max[float64](1.0, 3.14) - 传
nil时必须显式指定类型：var x *int; f(x)可以，但f(nil)会失败，得写f[*int](nil) - 如果函数返回值参与类型推导（比如作为 map 的 value），确保调用上下文有足够类型信息，否则加类型注解
约束太宽或太窄都会影响 API 可用性
约束不是越严越好，也不是越松越方便。比如给排序函数用 comparable，看似通用，但字符串切片和结构体切片行为完全不同，用户传进来才发现不能比较；反过来，若约束成 interface{ Len() int; Swap(i, j int) }，又把本可支持的原生切片排除了。
实操建议：
- 优先复用
golang.org/x/exp/constraints（已归入constraints包），它提供Ordered、Integer、Floating等合理分层 - 自己定义约束时，按最小必要原则：只加调用中真实用到的方法或类型限制
- 如果函数内部只做
len()和索引访问，用~[]T比用某个 interface 更直接且兼容原生切片
泛型约束最麻烦的地方不在语法，而在判断“这个函数到底需要什么能力”——多看标准库 sort 和 slices 包的约束写法，它们已经覆盖了绝大多数真实场景。写完记得用自定义类型和别名类型测一遍，很多坑只在这时候暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
