泛型约束写错会直接编译失败；必须用interface定义，禁用字段、值及非法~表达式；comparable用于==/!=场景但不保证map key安全；~int兼容类型别名而int不兼容；联合类型推导需参数类型一致。
泛型约束写错会直接编译失败，不是运行时报错；必须用 interface 定义，不能写字段、不能写值、不能混用 ~ 和具体类型以外的表达式。
comparable 约束怎么用才安全
需要支持 == 或 != 的场景（比如 map 的键、查找函数），必须用 comparable，不能用 any 或空接口。它是个内置约束，覆盖所有可比较类型（int、string、指针、结构体字段全可比较等），但不包括 slice、map、func、chan。
-
comparable不能嵌套在其他 interface 里再加方法，比如interface{ comparable; String() string }是非法的 - 若还需调用方法，应改用自定义约束 + 方法签名，例如
type Keyer interface{ comparable; Key() string } - 传入 struct 类型时，确保所有字段都满足可比较要求，否则编译报错：
invalid use of uncomparable type
~int 和 int 在约束里到底差在哪
~int 表示“底层类型为 int 的所有类型”，包括 type MyInt int 这类别名；而 int 只匹配 int 本身。项目中大量使用带语义的类型别名（如 type UserID int），用 int 会导致泛型调用失败。
- 正确写法：
type Integer interface{ ~int | ~int64 | ~uint32 } - 错误写法：
type Integer interface{ int | int64 | uint32 }——UserID无法传入 -
~只对基本类型有效（int、string、bool、float64等），对struct、interface、[]T、map[K]V无效
联合类型约束（int | float64）为什么有时推导失败
Go 编译器从参数推导泛型类型时，要求所有实参能统一映射到同一个 T。如果传 Max(1, 3.14)，1 是 int、3.14 是 float64，没有交集，推导失败。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误现象：
cannot infer T或cannot use 3.14 (untyped float constant) as T value - 字面量未显式类型化时，优先按默认类型（
int、float64、string）解释，不会自动向上兼容 - 解决方式：统一转成同一类型，如
Max[float64](1.0, 3.14)；或避免混合字面量，用变量传入（变量已有明确类型） - nil 值必须显式指定类型：
f[*int](nil)，不能写f(nil)
自定义约束该不该嵌入 io.Reader 这类标准接口
可以嵌入，但要注意行为约束和联合类型的组合逻辑。嵌入 io.Reader 表示“必须实现 Read 方法”，和数值类型约束是正交需求，不能混为一谈。
- 合法：
type ReadNumber interface{ io.Reader; ~int | ~float64 }—— 要求类型既可读又属于数值底层类型（极少用，仅作语法示意） - 更常见的是纯行为约束：
type ReaderWriter interface{ io.Reader; io.Writer } - 禁止在 interface 中声明字段：
type Bad interface{ Name string }会编译报错invalid receiver type - 约束越窄越好，避免用
any或空interface{}，那等于放弃类型检查
最易被忽略的一点：泛型约束不是“文档说明”，而是编译期强制契约；哪怕只漏一个常用别名（比如忘了 ~int32），下游用户就会卡住——得看清楚业务里实际用到了哪些自定义类型，再反推约束要不要加 ~、加哪些底层类型。
