泛型约束决定编译器能否推导操作合法性，T any 不支持 +、== 等操作因其无行为保证；需用 constraints.Ordered 或联合类型显式限定可比/可操作类型，嵌入接口要求方法签名完全匹配，约束过宽或过窄均影响性能与复用。
泛型约束不是“加个接口就完事”，它直接决定编译器能否推导操作合法性，写错会导致 invalid operation 或类型推导失败——比如想对 T 做 + 却没约束数值类型，Go 就会报错。
为什么 T any 不能做加法或比较
any 等价于 interface{}，只保证能存任意值，不提供任何操作能力。编译器看到 a + b 就懵：字符串、切片、结构体也支持 + 吗？不，只有部分类型支持，必须显式告诉它哪些可以。
-
T any下连==都可能出错（比如含 slice 或 map 的 struct） - 想用
<、>必须让T满足constraints.Ordered或手动列出可比类型 - 想调
.String()就得约束T实现fmt.Stringer
constraints.Ordered 和自定义联合类型的区别
constraints.Ordered 是标准实验包里的预定义约束（需导入 golang.org/x/exp/constraints），覆盖 int、string、float64 等常见可比类型；但它的底层仍是联合类型，和手写 int | int64 | string 语义一致，只是更省事。
- 用
constraints.Ordered时，nil不能参与比较（因为 interface{} 不在其中） - 手写联合类型更透明，比如
type ID interface{ int | string }，明确限定仅这两种类型可用于 ID 字段 - 注意：自定义联合类型里不能混入未导出类型或非基本类型（如未导出 struct），否则实例化时报错
嵌入接口约束时方法签名必须完全匹配
泛型约束中嵌入接口（如 io.Reader），要求实际类型实现的对应方法签名一字不差——包括参数名、顺序、是否指针接收者。
立即学习“go语言免费学习笔记（深入）”；
- 写
type ReadCloser interface{ io.Reader; io.Closer }，那么传入的类型必须同时实现Read([]byte) (int, error)和Close() error - 如果某个类型用
(*MyType).Read实现了io.Reader，但你传的是MyType值类型变量，就会因接收者不匹配而失败 - 方法返回值顺序错一位（比如
(error, int)vs(int, error)）也会被判定为不满足约束
泛型约束的性能影响常被忽略
约束本身不产生运行时开销，但过度宽泛的约束（如全用 any）会让编译器生成更多泛型实例，增大二进制体积；而过窄的约束（如只列 int）又失去复用价值。
- 推荐优先用
constraints.Integer而非手写int | int8 | int16 | int32 | int64 | uint | ...，语义清晰且未来新增整型自动兼容 - 避免在约束里塞无关方法：比如只要求加法，就别硬加上
MarshalJSON()—— 这会让本不该参与的类型无法实例化 - 真正容易踩的坑是：约束里写了方法，但没意识到该方法可能 panic（如
String()内部 panic），这不属于类型系统检查范围
