Go泛型约束是明确的接口类型，必须声明操作能力而非类型列表：需用~修饰底层类型、|联合类型、方法签名或预声明标识符，禁止字段定义；约束名须大写导出才能跨包使用；每个类型参数必须在函数体中被实际使用。
Go 泛型里 interface 类型约束不是“随便拼凑”，而是有明确语法边界和语义规则的组合体。写错一个符号、漏一个 ~、大小写不对，编译器就拒绝你——它不报模糊错误，只报硬性失败。
interface 类型约束必须是接口类型，interface{} 不算数
很多人一上来就写 func F[T interface{}](v T)，能编译，但函数体内连 v == v 都通不过。因为 interface{} 是空容器，不是约束：它不承诺任何操作能力。真正可用的约束必须让编译器知道「T 能干什么」。
- 带方法签名：比如
interface{ String() string }，表示 T 必须有String()方法 - 含预声明标识符：如
comparable（支持==/!=）、~int（匹配底层为 int 的所有类型） - 联合类型集合：如
~int | ~string，注意必须用|，不能写or或|| - 禁止字段定义：
interface{ Name string }是非法语法，接口只允许方法，不允许字段
~int 和 int 在约束中完全不是一回事
定义 type Milliseconds int 后，传给约束为 int 的泛型函数会失败；换成 ~int 就能过。因为 ~int 表示「底层类型为 int 的所有类型」，而 int 只匹配 int 本身。
- 单位类型（
type Bytes int64）、ORM 字段别名（type ProductID uint）都依赖~才能被泛型接纳 -
~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语言免费学习笔记（深入）”；
- Go 的约束本质是接口类型，遵循和普通类型一样的可见性规则：首字母小写 = 包私有
- 只要涉及跨包泛型函数，约束名就必须大写，如
Number，不能是number - 别试图用
_或注释绕过导出要求，编译器不认 - 如果约束只在当前包用，可以小写；但工程中多数泛型工具函数都需复用，建议统一导出
嵌入接口时，方法必须被实际调用，否则类型信息可能丢失
泛型约束里嵌入 io.Reader 是常见做法，但要注意：接口方法必须在函数体内被真实使用，否则编译器可能优化掉类型链，导致下游无法传入具体实现。
- 正确示例：
func ReadAll[T io.Reader](r T) ([]byte, error) { return io.ReadAll(r) }→r真实传给了io.ReadAll，类型链完整 - 错误示例：
func LogReader[T io.Reader](r T) { fmt.Printf("got reader: %v", r) }→r只被当interface{}打印，编译器会警告T is unused，且调用时可能因类型推导失败而报错 - 如果只想约束“能读”又不想强制调用
Read()，应改用更轻量的约束，比如any+ 运行时检查，而不是硬塞io.Reader - 每个类型参数都必须在函数体中至少被使用一次（作为参数、返回值或方法调用目标），否则 Go 编译器会拒绝推导
最常被忽略的点是：约束不是“类型白名单”，而是“操作契约”。你写的每一条 |、每一个 ~、每一处方法签名，都在向编译器声明「这个类型必须支持这些操作」——少一条，就断链；多一条，就过严。写约束前，先想清楚你要对 T 做什么，而不是先列类型。
