泛型约束必须显式声明且严格满足，any不提供操作能力，comparable、Stringer等需对应使用，~支持别名类型，导出约束名须大写，嵌入接口方法必须实际调用。
泛型约束不是“加个 [T any] 就完事”，它直接决定编译能否通过、类型是否安全、跨包能否复用。写错一个 ~、漏一个方法、首字母小写，函数就废一半。
泛型函数必须显式声明约束，any 不等于“随便传”
很多人以为 func F[T any](v T) 是万能兜底，其实它只表示“不施加额外限制”，但函数体内连 v == v 都会报错——因为 any（即 interface{}）不承诺任何操作能力。
- 要用
==或!=？必须写[T comparable]，这是编译器唯一能静态验证相等性的约束 - 要调用
.String()？约束得是fmt.Stringer，不是any - 要做加法？不能只写
int | float64，而要写~int | ~float64，否则type UserID int传不进去
~ 是别名类型能被接纳的关键，不是可选项
Go 中 type Milliseconds int 和 int 是两个不同类型，哪怕底层一样。泛型约束若写成 int，Milliseconds 就无法实例化；换成 ~int 才行。
-
~int | string合法：前者匹配所有底层为int的命名类型，后者是基础类型字面量 -
int | string编译失败：int单独出现不是有效类型集合成员 -
~string冗余但合法：因为string没有别名，加~不影响行为，但没必要
自定义约束名必须大写导出，否则跨包调用直接失败
在 utils 包里定义 type number interface{ ~int | ~float64 }，其他包调用 func Calc[T number]() 会报 cannot use number (not defined in this package)。
立即学习“go语言免费学习笔记（深入）”；
- 约束本质是接口类型，遵循 Go 的可见性规则：首字母小写 = 包私有
- 只要泛型函数需被其他包使用，约束名就必须大写，如
Number，不能是number - 即使当前包内用，也建议统一导出，避免后续迁移时重构成本
嵌入接口必须真实调用其方法，否则类型链可能被优化掉
常见写法 func ReadAll[T io.Reader](r T) ([]byte, error) 看似稳妥，但如果函数体里没调用 r.Read(...)，编译器可能丢弃该约束路径，导致下游传入具体实现（如 bytes.Reader）时类型不匹配。
- 嵌入
io.Reader必须在函数体内至少一次调用Read方法，否则约束失效 - 同理，若约束含
fmt.Stringer，就得调用v.String()，哪怕只是_ = v.String() - 这不是风格问题，是编译器对“约束是否被实际使用”的硬性检查
最常被忽略的其实是约束的“实际使用”要求：方法签名写了，但没调用；~ 加了，但忘了导出；comparable 用了，却往里面塞了含未导出字段的 struct —— 这些都不是运行时报错，而是编译期静默拒绝，查起来特别费时间。
