泛型非语法糖，编译期实例化，需约束comparable才能用于==或map key；含slice/map/func的结构体不可比较，应改用JSON或自定义哈希；Map性能略低5–10%，但业务场景中影响甚微。
泛型不是语法糖，它在编译期完成类型实例化，能真正消除重复函数、避免 interface{} 带来的运行时类型断言和装箱开销——但前提是用对约束、避开不可比较类型陷阱。
泛型函数必须显式约束 comparable 才能用于 map key 或 == 判断
很多初学者写完 func Dedupe[T any](s []T) []T 就直接拿去处理结构体切片，结果编译报错：invalid operation: cannot compare s[i] == s[j] (operator == not defined for T)。这是因为 any 不保证可比较，而去重、查找、map 键等操作都依赖 ==。
- 正确做法是把约束收紧为
T comparable，Go 标准库的slices.Compact也是这么做的 - 如果结构体含
slice、map、func字段，它本身就不满足comparable，强行用泛型会编译失败，此时得退回到 JSON 序列化或自定义哈希键方案 - 简单类型如
int、string、struct{ Name string; ID int }（所有字段都可比较）可直接用comparable
func Map[T, U any](s []T, f func(T) U) []U 的实际性能比手写循环略低但可接受
泛型 Map 看起来优雅，但实测中它比针对具体类型的循环慢约 5–10%，主要来自闭包调用开销和泛型实例化后的内联限制。不过这种差距在业务逻辑远重于遍历本身的场景里几乎不可感知。
- 不要为纯数值计算（如每项乘 2）盲目套用
Map；小规模数据（ - 当转换逻辑复杂（如 HTTP 响应解析 + 字段映射 + 默认值填充），
Map能显著提升可读性和测试覆盖率 - 注意：闭包捕获外部变量时，泛型函数仍会正确推导类型，但逃逸分析可能让参数分配到堆上
泛型结构体如 Stack[T any] 必须小心 Pop() 的零值返回
泛型容器方法返回零值时，var zero T 是安全的，但容易忽略的是：如果 T 是指针类型（如 *User），零值是 nil，这没问题；但如果 T 是含非零字段的结构体，调用方可能误以为“有值”而直接解引用。
-
Pop()方法应始终配合布尔返回值（如func Pop() (T, bool)），不能只靠零值判断是否成功 - 避免在泛型方法里做
if reflect.ValueOf(item).IsNil()这类反射判断——它破坏了泛型的编译期类型安全，也带来明显性能损耗 - 标准库
container/list不支持泛型，所以自己实现栈/队列时，泛型结构体仍是目前最干净的选择
最常被跳过的细节是：泛型代码一旦被多个包导入，每个包都会生成独立的实例化版本，可能导致二进制体积微增；若只在单一包内高频使用（如内部工具函数），影响几乎为零，但跨服务共享泛型组件时，得留意构建产物大小变化。
