泛型切片去重应约束T为comparable而非any，因any不可比较且丧失类型安全；FilterMap可合并过滤与转换避免重复遍历；Sort应复用sort.Slice而非封装值比较函数；集合操作无需context，除非涉及I/O。
泛型切片去重为什么不能直接用 map[any]bool？
Go 的泛型切片去重，很多人第一反应是 map[any]bool，但这样会丢失类型信息，编译失败——any 无法作为 map 键参与比较（比如结构体没实现 Equal 方法时），而且 any 会让后续操作失去类型约束，容易在运行时出错。
正确做法是让泛型参数 T 约束为可比较类型：comparable。这是 Go 泛型最常用也最关键的约束之一。
-
func Dedup[T comparable](s []T) []T是安全起点 - 如果元素是自定义 struct，必须确保所有字段都满足
comparable（不能含slice、map、func） - 若需支持不可比较类型（如含
[]int的 struct），得改用reflect.DeepEqual，但性能差、无编译期检查，不推荐常规使用
Filter 和 Map 操作怎么避免反复遍历？
写泛型集合操作时，常见错误是把 Filter 和 Map 拆成两个独立函数调用，导致原切片被遍历两次。实际中多数场景可以合并——尤其当业务逻辑简单时，一次遍历更高效。
例如：从用户列表中筛选活跃用户并提取其邮箱，不必先 Filter 再 Map，而是直接 FilterMap：
立即学习“go语言免费学习笔记（深入）”；
func FilterMap[T, U any](s []T, f func(T) (U, bool)) []U {
dst := make([]U, 0, len(s))
for _, v := range s {
if u, ok := f(v); ok {
dst = append(dst, u)
}
}
return dst
}
-
f返回(U, bool)，兼顾过滤与转换，语义清晰 - 预分配容量
len(s)避免多次扩容，但注意实际结果可能更少，属于空间换时间 - 不要试图用泛型约束
T和U的关系（比如要求T实现某个接口），那会大幅增加调用方负担
为什么 Sort 不该直接泛型化 sort.Slice？
sort.Slice 已经是泛型友好设计，但它接受的是 func(i, j int) bool，不是基于元素值的比较函数。直接封装成 Sort[T any](s []T, less func(T, T) bool) 看似简洁，实则绕过了 Go 运行时对切片底层的优化，且无法复用 sort.Interface 生态（比如 sort.Stable）。
- 推荐组合已有工具：用
sort.Slice+ 匿名函数，明确传入索引，性能无损 - 若真要封装，应保留
sort.Slice原签名风格，而非强行改成值比较——Go 的惯用法优先考虑可读性和运行时效率，不是语法糖数量 - 对
[]string或[]int这类基础类型，直接用sort.Strings/sort.Ints，它们是专用汇编优化版本，比泛型版快不少
泛型集合函数要不要加 context.Context？
绝大多数泛型集合操作（Filter、Map、Dedup）是纯内存计算，不涉及 I/O、网络或阻塞调用，加 context.Context 不仅多余，还会污染函数签名、干扰类型推导，让调用方必须显式传 context.Background()。
- 只有当你在泛型函数内部触发 HTTP 请求、数据库查询、或调用其他带 context 的函数时，才需要透传 context
- 即便如此，也不建议把 context 塞进集合操作主函数里，而应拆出单独的“带上下文的数据获取层”，再把结果交给泛型处理层
- 泛型的本质是抽象数据形态，不是抽象执行环境；混用会导致职责不清，测试困难，且无法内联优化
泛型集合函数真正难的不是写出来，而是判断哪些地方不该泛型化——比如排序策略、错误处理路径、或需要反射的边界情况。这些地方硬套泛型，反而让代码更脆弱。
