泛型约束必须是接口类型，interface{}虽可编译但不提供任何操作保证，真正可用的约束需含方法签名、comparable、~int或联合类型等；~int支持别名类型而int不支持，自定义约束名须大写导出，且推荐手写Integer等接口避免x/exp依赖。
泛型约束必须是接口类型，interface{} 不能当约束用
直接写 func F[T interface{}](v T) 能编译，但函数体内连 v == v 都报错：invalid operation。因为 interface{} 不提供任何操作保证，它只是个值容器，不是约束——约束的职责是告诉编译器「T 支持哪些操作」。
真正能用的约束必须是接口类型，且至少满足以下之一：
- 带方法签名，比如
interface{ String() string } - 含预声明标识符，如
comparable、~int - 联合类型集合，如
~int | ~string（注意必须用|，不是or）
常见错误是把结构体字段当约束写：interface{ Name string } —— 这语法非法，Go 接口只允许方法，不允许字段。
~int 和 int 在约束里完全不是一回事
定义 type MyInt int 后，MyInt 值传给约束为 int 的泛型函数会失败；但换成 ~int 就能过。因为 ~int 表示「底层类型为 int 的所有类型」，而 int 只匹配 int 本身。
立即学习“go语言免费学习笔记（深入）”；
实际项目中，单位类型（如 type Milliseconds int）、ORM 字段别名（如 type UserID int64）都依赖 ~ 才能被泛型接纳。
混用时注意规则：
-
~int | string合法：~ 修饰具体类型，string是可直接出现在联合中的类型字面量 -
int | string非法：编译报错int is not a type -
~int | ~string合法但冗余：string本身不可再有别名，加~没实际意义
自定义约束名必须大写导出，否则跨包调用直接失败
写 type number interface{ ~float64 | ~int } 看似没问题，但如果在 utils 包里定义，其他包调用 func Calc[T number]() 会提示 cannot use number (not defined in this package)。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
根本原因是 Go 的约束本质是接口类型，遵循和普通类型一样的可见性规则：首字母小写 = 包私有。
解决办法只有两个：
- 约束名首字母大写，如
Number - 确保调用方 import 的是定义该约束的包路径（不是当前文件路径）
别试图用 _ 或注释绕过——编译器不认，IDE 也补全不出来。
用 golang.org/x/exp/constraints 要小心未来兼容性
虽然 constraints.Integer、constraints.Ordered 写起来省事，但它还在 x/exp 下，不是标准库。2026 年中仍无合并进 std 的明确计划，部分团队已开始手写等效接口避免锁定。
如果你用它，得接受两点现实：
- 必须显式
go get golang.org/x/exp/constraints，CI 流程要多一步 - 某天它被废弃或重命名，所有
import和约束引用都要批量改
更稳的做法是复制它的核心定义到自己包里，比如：
type Integer interface{ ~int | ~int8 | ~int16 | ~int32 | ~int64 | ~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64 | ~uintptr }
这样既免依赖，又保留了 ~ 对别名类型的兼容——这才是生产环境最常被忽略的细节。
