泛型约束是编译器拦截错误的关键防线：any放弃类型安全，无法比较或运算；comparable用于==、map key、去重，要求类型字段全可比；constraints.Ordered提供全序比较支持，需导入官方扩展包。
泛型约束不是语法糖，它是编译器能帮你拦住错误的唯一防线。没加约束的 T any 看似自由，实则等于放弃类型安全——你不能对它做比较、不能相加、不能调方法，最后只能打印或传参。
comparable 约束：什么时候必须用它？
当你需要在泛型函数里用 == 或 !=，或者想把类型当 map 的 key、放进 set 去重，就必须用 comparable。
-
comparable是 Go 内置约束，覆盖所有支持==的类型（int、string、struct（字段全可比）、[...]T等），但不包括slice、map、func、chan - 常见错误：
func Find[T any](s []T, target T) int里写v == target→ 编译失败，因为any不保证可比 - 正确写法：
func Find[T comparable](s []T, target T) int，这时传[]string或[]int都行，但传[][]int会报错（切片不可比）
constraints.Ordered：别直接手写数值联合类型
Go 标准库没内置 Ordered，但它在 golang.org/x/exp/constraints 包里——这是官方推荐的有序类型约束，比手动列 int | int8 | float64 | string 更可靠。
- 手写联合类型容易漏：比如忘了
uint64，或误加bool（bool不支持） -
constraints.Ordered已验证所有成员支持、<code>>、、<code>>=，且包含string（按字典序） - 注意：这个包仍是
exp（实验性），但已被大量生产项目采用；Go 1.22+ 已开始讨论将其移入标准库 - 示例：
func Min[T constraints.Ordered](a, b T) T { return min(a, b) }，可安全传3、3.14、"apple"
自定义接口约束：要最小，不要最大
当你需要调用某个方法（比如 .String() 或 .Close()），就该用接口约束，但接口定义必须只包含实际用到的方法。
立即学习“go语言免费学习笔记（深入）”；
- 反例：
type Stringer interface { fmt.Stringer; io.Reader }—— 即使函数只调.String()，也强制要求实现Read()，过度约束 - 正例：
type Stringer interface { String() string }，干净、明确、易满足 - 组合已有接口更安全：
type ReadCloser interface { io.Reader; io.Closer }比自己重新定义一套方法更少出错 - 陷阱：空接口
interface{}和any不等于“什么都能干”，它只是“什么类型都接受”，不代表能执行任何操作
any 和 interface{}：它们真的一样，但别滥用
any 就是 interface{} 的别名，语义上表示“任意类型”，但它不提供任何能力——你不能对 T any 做任何运算或方法调用，除非先断言。
- 适用场景：仅用于透传、反射、日志打印等不依赖具体行为的上下文
- 危险操作：
func Add[T any](a, b T) T { return a + b }→ 编译失败，+不属于any的契约 - 替代思路：如果需要加法，用
Numeric约束；如果需要字符串化，用fmt.Stringer；any不该是兜底方案，而是明确无约束意图的标记 - 性能提示：
any会触发接口装箱，对高频小对象（如int）有微小开销；泛型单态化后，T constraints.Ordered生成的是纯值类型代码，无装箱
最常被忽略的点：约束不是越宽越好，而是越精确越好。一个泛型函数声明了 T io.ReadWriter，却只用了 .Write()，那它其实只需要 io.Writer——多出来的 Read() 要求，会无谓限制调用方。
