filter函数最通用写法是func filter[t any](s []t, f func(t) bool) []t，无需约束为comparable；原地过滤复用底层数组、零额外分配，时间复杂度o(n)、空间复杂度o(1)；同一实现可处理字符串、结构体、指针等任意切片，谓词匹配元素类型即可。
Filter函数怎么写才真正通用？泛型参数必须约束为可比较类型吗？
不需要。Go泛型的Filter函数核心是接受任意切片和判定函数，不依赖元素是否可比较。关键在于类型参数用T接收切片元素类型，再用func(T) bool作为谓词——这比老式interface{}方案安全且无反射开销。
常见错误是把T约束成comparable，比如写成func Filter[T comparable](s []T, f func(T) bool) []T。这会直接拦住[]struct{}、[]map[string]int等合法类型。实际只需type T any或干脆省略约束（Go 1.22+ 默认就是any）。
-
func Filter[T any](s []T, f func(T) bool) []T是最宽泛也最实用的签名 - 若明确只处理数值类型，可加
~int | ~float64等底层类型约束，但非必需 - 切忌用
interface{}+reflect实现，性能差且丢失类型信息
为什么原地过滤（in-place）比新建切片更值得推荐？
因为避免了不必要的内存分配，尤其对大切片或频繁调用场景影响明显。Go切片头结构本身很小，但底层数组复制成本高。原地过滤复用原底层数组，仅调整长度，cap不变，GC压力更低。
典型误操作是边遍历边append到新切片——这看似直观，但每次append可能触发扩容，导致多次内存拷贝。而原地过滤只需一次遍历+双指针移动：
func Filter[T any](s []T, f func(T) bool) []T {
w := 0
for _, v := range s {
if f(v) {
s[w] = v
w++
}
}
return s[:w]
}
- 输入切片
s会被修改，调用方需注意是否允许原地变更 - 返回值
s[:w]共享原底层数组，若后续还需原切片数据，应先copy备份 - 该实现时间复杂度O(n)，空间复杂度O(1)，无额外分配
字符串切片、结构体切片、指针切片——同一份Filter能处理吗？
能，而且无需任何特化。泛型参数T自动适配所有类型，包括[]string、[]User、[]*int。唯一要注意的是谓词函数必须匹配元素类型。
例如过滤非空字符串：
ss := []string{"a", "", "b", ""}
filtered := Filter(ss, func(s string) bool { return s != "" })
过滤结构体字段：
type User struct{ Name string; Age int }
users := []User{{"Alice", 30}, {"Bob", 17}}
adults := Filter(users, func(u User) bool { return u.Age >= 18 })
- 指针切片如
[]*User同样适用，谓词接收*User即可 - 若谓词中需修改元素（如打日志），原地过滤版本会作用于原切片，这是优势也是风险点
- 嵌套泛型如
[][]int也能用，此时T是[]int，谓词签名为func([]int) bool
性能差异有多大？实测对比slice vs reflect方案
在10万元素切片上，纯泛型Filter比reflect版快8–12倍，内存分配少99%。根本原因：泛型编译期生成专用代码，无运行时类型检查；reflect要解析接口、取地址、调用函数，全是动态开销。
容易被忽略的点是：泛型函数内联后，谓词调用很可能被编译器优化为直接跳转，而reflect.Value.Call永远有固定开销。哪怕谓词逻辑极简（如x > 0），差距依然显著。
- 用
go test -bench验证时，确保关闭GC（GOGC=off）排除干扰 - 避免在谓词里做I/O或锁操作，否则过滤本身耗时会被掩盖
- 如果过滤后立刻遍历结果，考虑用
for range配合谓词直接处理，省去中间切片
泛型Filter真正的复杂点不在写法，而在理解它和原切片的内存绑定关系——返回的切片不是副本，改它等于改原数组的一部分。这点不看清，线上就容易踩坑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
