Comparable接口仅支持自然排序且要求类自身实现，无法满足多标准、外部定制或未修改类的排序需求；Comparator接口则提供外部灵活比较能力，弥补其不足。
泛型约束不是“加个接口就行”，而是决定函数能不能编译、能不能用的关键开关。写错约束，函数写得再漂亮也调用不了。
comparable 为什么经常不够用
comparable 看似万能，但它只保证 == 和 != 可用，不提供 、<code>len()、方法调用等能力。很多初学者写了 [T comparable] 后发现 if a 报错，或想对 <code>T 调用 String() 却提示未定义——这不是 bug，是约束没写对。
- 需要排序或比较大小：必须用
constraints.Ordered（需go get golang.org/x/exp/constraints），或自己写interface{ ~int | ~string | ~float64 } - 需要调用方法：约束里必须显式包含该方法签名，例如
interface{ Read([]byte) (int, error) }，不能指望comparable自动带出来 - 需要
len()或遍历：comparable完全无效；得用具体容器类型（如[]T）或自定义约束（如type Sliceable interface{ ~[]int | ~[]string }）
~int 和 int 在约束里差在哪
写 func F[T int](x T)，传 type Millis int 的值会直接编译失败；但改成 func F[T ~int](x T) 就能过。因为 int 只匹配 int 本身，而 ~int 表示“底层类型为 int 的所有类型”——单位类型、状态码别名、ORM 字段类型几乎都靠它活。
-
~只能用于基本类型：~int、~string、~bool合法；~struct{}、~map[string]int是语法错误 - 结构体、切片、map 等复合类型不能加
~，只能靠接口方法约束（比如要求实现MarshalJSON() ([]byte, error)） - 别名类型（如
type UserID int）在真实项目中极常见，不用~就等于主动拒绝它们
constraints 包要不要用
结论很直接：可以临时用，但别当标准库依赖。它还在 x/exp 下，API 不稳定，且 constraints.Ordered 不支持自定义结构体（哪怕实现了 Less()），也不兼容 uintptr 或用户定义的整数别名（除非你手动加 ~）。
立即学习“go语言免费学习笔记（深入）”；
- 要快速验证逻辑：
import "golang.org/x/exp/constraints"+[T constraints.Integer]没问题 - 进生产核心模块：优先手写
interface{ ~int | ~int64 | ~uint }，或封装成自己的Number接口，避免未来迁移风险 - 注意
go get golang.org/x/exp/constraints必须执行，否则 import 会报错；且go.mod里要出现对应依赖行才算生效
类型推导失败时别硬扛
Go 编译器只在参数类型完全一致时才推导泛型类型。以下情况必然失败：Max(1, 3.14)（int vs float64）、F(nil)（nil 无类型信息）、make([]T, 0)（上下文无实参可反推）。
- 遇到
cannot infer T或cannot use ... as T value，第一反应不是改约束，而是显式写出类型参数：Max[float64](1.0, 3.14)、F[*int](nil)、Stack[string]{} - 字面量常量（如
"hello"、42）在泛型调用中容易推导失败，统一加类型后缀更稳："hello"[0]是byte，42.0是float64 - 如果函数返回值参与推导（比如作为 map 的 value），确保调用处有足够类型注解，否则加
var _ map[string]T = f()这类占位声明
最常被忽略的一点：约束不是越宽越好，也不是越窄越安全。写 [T any] 看似灵活，结果连 == 都用不了；写 [T constraints.Ordered] 看似严谨，却把用户自定义的可比较结构体拦在门外——真正关键的是根据函数实际要做的操作，最小化收束约束。
