泛型函数不能仅用T any，必须合理设计约束：any仅保赋值安全，不支持比较等操作；comparable保障==/!=可用但仍有坑；需结合外置逻辑或精准接口约束确保行为可靠。
泛型函数不是“加个[T any]就能通用”，关键在约束设计和调用边界控制——写错约束或忽略比较逻辑，编译能过，运行时行为却不可靠。
泛型函数签名里 T any 够用吗
够用但危险。它只保证类型可赋值，不保证可比较、可排序、可相加。比如你写一个 Max[T any](a, b T) T，传入两个 struct{} 就会编译失败（invalid operation: a > b (operator > not defined on struct {})），但编译器不会提前报错，而是在实例化时才暴露问题。
- 用
T comparable至少能确保==和!=可用，适合去重、查找存在性等场景 - 需要大小比较？别硬套
constraints.Ordered（已移除），也别手写冗长的~int | ~string | ...联合约束——它漏掉自定义类型，且无法覆盖[3]int这类满足接口但不能直接比大小的类型 - 真正灵活的做法是把比较逻辑外放：
func Max[T any](a, b T, less func(T, T) bool) T，约束只保底any，行为由调用方决定
什么时候必须显式指定类型参数
类型推断不是万能的，以下情况不写清楚 [T] 会编译失败：
- 调用时参数类型不明确，比如
fmt.Println接收interface{}，PrintSlice([]int{})能推，但PrintSlice(make([]int, 0))可能因上下文缺失而失败 - 函数返回值参与后续操作，而编译器无法从右侧反推左侧类型，例如
var x = Map(...)，若没给Map指定[int, string]，x 类型就是interface{} - 调用带多个类型参数的函数，如
Map[T, U any]，只传一个切片，U 无法推导，必须写成Map[int, string](s, f)
comparable 约束下仍可能 panic 的地方
comparable 保证 == 合法，但不保证安全。这些坑容易被忽略：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 含
func、map、slice字段的 struct 不满足comparable，即使你声明了T comparable，传入也会编译报错：invalid use of type T as a comparable type - 指针比较（
&a == &b）和值比较（a == b）语义不同，泛型函数里若默认用==，对指针类型就可能误判相等 - 浮点数用
==判断相等极不可靠，comparable允许你这么做，但业务上大概率要改用误差范围判断——泛型本身不解决这个问题，得靠约束之外的文档或额外参数提醒
泛型函数性能开销真实吗
没有运行时开销。Go 泛型是单态化（monomorphization）实现：编译期为每个实际类型生成独立函数副本，和手写 MaxInt、MaxString 生成的机器码完全一致。
- 但要注意：泛型函数体太大 + 类型参数太多，会导致编译时间上升、二进制体积膨胀，尤其是嵌套泛型（如
func F[T interface{~[]U}, U any]） - 避免在热路径上泛化“本就不该通用”的逻辑，比如一个只处理
uint64时间戳的校验函数，硬套[T comparable]只是徒增理解成本 - 如果函数逻辑依赖反射或
unsafe，泛型反而会让代码更难维护——泛型的价值在于类型安全下的复用，不是给任意代码套壳
最常被跳过的一步是：写完泛型函数后，没用至少两种差异大的类型（比如 int 和自定义 type ID string）跑一遍单元测试，结果上线后遇到用户传了个带 map 字段的结构体，直接卡在编译阶段。
