Go泛型约束是接口定义与类型集合的组合，必须显式声明；any是最宽泛约束但仅支持interface{}操作，数值运算需Integer等具体约束，comparable不保证map key安全。
Go 泛型约束不是“写法问题”，而是“接口定义 + 类型集合”的组合表达；不写约束会编译报错，写错约束会导致函数无法被调用或操作符不可用。
泛型函数必须显式带约束，any 不是省略，而是最宽泛的约束
很多人以为不写约束就能泛化，但 Go 要求每个类型参数 T 后面必须跟一个接口类型的约束。空接口 interface{} 或其别名 any 是合法约束，但它只保证值能被传入，不保证能做任何操作（比如 +、==）。
-
any允许传任意类型，但函数体内只能调用fmt.Println这类接受interface{}的操作，不能做算术或比较 - 想用
+，就得约束为数值类型，比如int | int64 | float64 - 想用
==，必须用comparable约束（或自己定义含~的近似类型接口）
错误示例：func Add[T any](a, b T) T { return a + b } → 编译失败：invalid operation: a + b (mismatched types)
用 golang.org/x/exp/constraints 是最快上手方式，但注意它未进标准库
官方提供的 constraints 包（如 Ordered、Integer、Float）本质就是预定义好的接口，直接 import 就能用，避免手写冗长联合类型。
立即学习“go语言免费学习笔记（深入）”；
-
constraints.Ordered包含所有可比较且支持的类型（<code>int、string、float64等），适合Max/Min类函数 -
constraints.Integer=Signed | Unsigned，比手动列int|int8|uint16|...更可靠 - ⚠️ 注意：该包仍在
x/exp下，不是std，需go get golang.org/x/exp/constraints，且未来可能迁移或废弃
正确示例：func Sum[T constraints.Integer](s []T) T { var sum T; for _, v := range s { sum += v }; return sum }
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
自定义约束要小心 ~ 操作符，否则结构体/别名类型会意外被拒
当你定义 type MyInt int，再用 int 做约束时，MyInt 默认不满足——Go 泛型默认只认“底层类型完全一致”，除非你显式用 ~ 表示“底层类型为…”。
- 写
interface{ int }→ 只接受int，不接受MyInt - 写
interface{ ~int }→ 接受所有底层是int的类型（MyInt、AnotherInt都行） - 结构体类型无法用
~，所以若想约束为“某个结构体或它的别名”，得靠方法集（比如要求实现String() string）
典型坑：type ID int; func Get[T interface{ int }](v T) → Get(ID(123)) 报错：ID does not satisfy interface{ int }
comparable 约束不是万能的，map key 和 switch case 仍受限
虽然 constraints.Comparable 能让 == 在泛型里工作，但它不等于“所有能做 == 的类型都安全”——Go 对 map key 和 switch 的类型检查更严格。
-
map[T]V中的T必须是 comparable，但像[]int、struct{ f []int }即使满足comparable约束，也不能作 map key（因为切片本身不可比较） -
switch v := any.(type)中的v类型推导不受泛型约束影响，该报错还是报错 - 函数返回
comparable类型不等于能塞进map，得看具体值是否真可比较
一句话：约束解决的是编译期类型合法性，不是运行期行为兜底。
真正难的不是怎么写约束，而是判断「这个操作到底依赖哪些底层能力」——加法要算术类型，查找要可比较，排序要有序，序列化要可反射……漏掉一点，就卡在编译器报错里出不来。
