Go泛型约束是编译期强制校验的类型集合声明，非语法糖；不加约束则无法使用+等操作符，必须通过接口（如comparable、~int或自定义约束）明确限定类型能力。
Go泛型约束不是“可选加分项”，而是类型安全的强制门槛——不加约束的泛型函数在涉及操作符（如 +、、<code>==）或方法调用时，99%会直接编译失败。
为什么 T any 不能直接做加法？
因为 any 等价于 interface{}，它不承诺任何行为。编译器无法确认 T 是否支持 + 运算符，所以像 sum += v 这样的语句会报错：operator + not defined on T。
- 错误写法：
func Sum[T any](s []T) T { var sum T; for _, v := range s { sum += v } }→ 编译失败 - 正确路径：必须通过约束告诉编译器 “这个
T是数值类型”，例如用type Numeric interface{ int | float64 } - 底层逻辑：约束本质是类型集（type set），编译器只允许对集合内明确列出的类型执行对应操作
comparable 是最常被低估的基础约束
只要函数里出现 == 或 !=，就必须显式加 comparable。这不是风格问题，是编译器硬性要求。
- 典型错误场景：
func Find[T any](s []T, target T) int里写if v == target→ 报错：invalid operation: v == target (operator == not defined on T) - 修复方式：改用
func Find[T comparable](s []T, target T) int - 注意：
comparable不包含 slice、map、func、struct 含不可比较字段等类型，传入这些会触发编译错误，而非运行时 panic
自定义约束接口别写成“大而全”
比如为支持 String() 和 Len() 就定义一个同时含两个方法的接口，看似方便，实则大幅降低复用性——很多类型只实现其中一个。
立即学习“go语言免费学习笔记（深入）”；
- 推荐做法：拆成最小粒度约束，例如
type Stringer interface{ String() string }和type Lenner interface{ Len() int } - 组合使用时用联合约束：
func PrintAndLen[T Stringer & Lenner](v T) - 反模式：
type Heavy interface{ String() string; Len() int; MarshalJSON() ([]byte, error) }→ 大部分类型无法满足，约束形同虚设
~int 和 int 的区别直接影响底层兼容性
int 只匹配字面量 int 类型；~int 匹配所有底层类型为 int 的别名（如 type MyInt int）。
- 若约束写
type IntOnly interface{ int }，则MyInt(5)无法传入 - 若写
type IntLike interface{ ~int }，MyInt就能通过检查 - 实际项目中，尤其对接 Cgo 或外部库时，
~前缀常是能否打通类型的分水岭
真正难的不是写出能编译的约束，而是预判哪些操作需要约束、哪些类型会被传入、以及约束过宽或过窄带来的维护成本——这往往要等到第二轮重构时才暴露出来。
