comparable约束仅保证类型支持==和!=编译通过，不保证逻辑正确或可作map key；满足条件的类型需所有字段均可比较，切片、map、func、channel等不可比。
泛型不是“多写几行就能用”的语法糖，它直接决定你写的通用函数能不能编译通过、会不会在运行时 panic、甚至影响二进制体积——关键不在“会不会写”，而在“约束怎么选”。
泛型函数必须显式声明 comparable 才能用 == 或当 map key
很多刚写 func Dedupe[T any](s []T) []T 的人，一传入结构体切片就报错：invalid operation: cannot compare s[i] == s[j]。这是因为 any 不保证可比较，而去重、查找、map 键等操作都依赖 ==。
- 正确做法是把约束收紧为
T comparable，Go 标准库的slices.Compact就是这么做的 - 如果结构体含
[]string、map[string]int或func()字段，它本身就不满足comparable，强行用会编译失败 - 此时得退回到 JSON 序列化或自定义哈希键方案，比如
fmt.Sprintf("%v", v)（仅限调试）或实现func (x MyStruct) Hash() uint64
不要用 any 做数值计算或字符串处理的泛型约束
any 等价于 interface{}，它让泛型失去类型检查能力，和反射、类型断言一样危险。
- 数值运算应使用
constraints.Ordered（标准库）或自定义Numeric接口，例如：type Numeric interface{ int | int8 | float64 } - 字符串相关操作（如拼接、截取）可用
StringLike interface{ string | []byte } - 用
~int64能同时接受int64和自定义类型type UserID int64，避免强制转换
泛型结构体 Pop() 返回零值时极易误判
Stack[T any] 这类容器的 Pop() 方法若只返回 T，调用方无法区分“栈空”和“弹出零值”。
- 指针类型（如
*User）的零值是nil，没问题；但结构体类型（如User{ID: 0, Name: ""}）的零值是合法值 - 必须配合布尔返回值：
func (s *Stack[T]) Pop() (T, bool)，而不是func Pop() T - 别在泛型方法里加
reflect.ValueOf(item).IsNil()—— 它破坏编译期类型安全，还拖慢性能
泛型实例化发生在编译期，跨包使用会增大二进制体积
泛型不是运行时动态生成代码，而是编译器为每个实际类型参数生成一份独立函数/结构体副本。
- 同一个
Map[int, string]和Map[string, int]会产生两份完全不同的机器码 - 如果泛型代码只在一个包内高频使用（比如内部工具函数），体积影响几乎为零
- 但若被多个服务共用、且实例化类型极多（如
Map[User, Order]、Map[Product, Review]…），二进制可能悄悄膨胀数 MB
最常被跳过的细节：泛型真正难的不是语法，而是判断“这个类型是否满足约束”——它不报错在 IDE 里，只在 go build 那一刻才甩你一个 cannot use ... as ... constraint。写之前，先想清楚你要支持哪些类型、哪些操作、哪些字段是否可比较。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
