Go泛型约束是编译期强制校验的类型集合声明，非语法糖；constraints包需手动go get下载，Ordered仅匹配原生可比较类型，~int支持类型别名而int不支持，自定义约束须大写导出。
Go 泛型约束不是“语法糖”，而是编译期强制校验的类型集合声明；constraints 包是实验性工具，不能替代对 interface + ~ 本质的理解。
为什么 import "golang.org/x/exp/constraints" 后还报错找不到包
这不是路径写错，而是包根本没下载到本地模块缓存中。Go 不会自动拉取 x/exp 下的实验包，必须显式触发。
- 运行
go get golang.org/x/exp/constraints（注意是go get，不是go install） - 确认
GO111MODULE=on已启用（可通过go env GO111MODULE检查） - 检查
go.mod是否新增了类似golang.org/x/exp v0.0.0-20260520123456的依赖行；若没有，说明下载未生效 - 某些 IDE（如旧版 Goland）可能缓存了模块索引，需手动刷新 Go Modules
constraints.Ordered 为什么不能用在自定义 struct 上
constraints.Ordered 是预定义的联合类型接口，只覆盖语言原生支持 < 的类型：比如 int、string、float64，但不包括任何结构体，哪怕它实现了 Less() 方法。
- 它等价于
interface{ ~int | ~int8 | ~int16 | ~int32 | ~int64 | ~uint | ... | ~string }，不含方法，只靠底层类型匹配 - 如果你写
type User struct{ ID int; Name string }，即使字段全可比较，User也不满足constraints.Ordered - 想让结构体参与泛型比较，必须自己定义带方法的约束，例如
type Ordered interface{ Less(Other any) bool }，再让结构体实现该方法 -
comparable同样不接受含切片、映射或函数字段的 struct —— 这是语言限制，不是约束写得不够宽
~int 和 int 在约束里到底差在哪
差在是否兼容类型别名。Go 泛型默认只认底层类型一致，而 ~ 是显式告诉编译器：“只要底层是 int，不管叫什么名字都算数”。
立即学习“go语言免费学习笔记（深入）”；
- 定义
type Millis int，再写func Sum[T int](s []T) T→Sum[Millis](...)编译失败 - 改成
func Sum[T ~int](s []T) T→Millis可以传入，因为~int匹配所有底层为int的类型 -
~只能用于基本类型：~int、~string、~bool合法；~[]int、~map[string]int、~struct{}都是语法错误 - 复合类型（数组、切片、map）要约束，只能列具体类型，或用带方法的接口，比如
type Sliceable interface{ Len() int }
自定义约束为什么首字母必须大写
Go 的泛型约束本质是接口类型，和其他类型一样受导出规则约束。小写约束在其他包不可见，会导致调用方无法实例化泛型函数。
- 写
type number interface{ ~int | ~float64 }（小写number）→ 其他包调用func Calc[T number]()会报错：undefined: number - 必须写成
type Number interface{ ~int | ~float64 }（大写Number），才能被外部引用 - 如果约束只在当前包内使用，小写合法；但一旦涉及跨包泛型，就必须导出
- 别名类型（如
type MyInt int）本身也要导出，否则即使约束用了~int，调用时仍可能因类型不可见而失败
真正容易被忽略的是：约束不是越“通用”越好。比如给 map key 写 [K comparable] 看似稳妥，但用户传入 struct{ f func() } 会在调用处才报错，而不是定义约束时——这会让问题暴露滞后。实际应按最小必要原则设计约束，必要时拆分成多个更窄的约束组合。
