slices.contains 仅在 go 1.21+ 可用，需先检查 go version；仅支持 comparable 类型切片，空切片返回 false，无自定义比较逻辑，性能等同手写循环。
slices.Contains 在 Go 1.21+ 中才可用，低于该版本直接调用会编译失败——别急着改代码，先确认你的 Go 版本。
确认 Go 版本并启用 slices 包
Go 的 slices 包是标准库的一部分，但仅从 1.21 开始稳定提供。运行 go version 检查是否 ≥ 1.21；若为 1.20 或更早，slices.Contains 不可用，强行导入会报错 undefined: slices.Contains。
- Go 1.21+：直接导入
"slices"即可使用 - Go 1.20 及以下：必须手写循环，或升级 Go，或使用第三方库（如
golang.org/x/exp/slices，但它是实验包，不建议用于生产） - 注意：不要混淆
slices（小写 s）和旧版社区常见的sliceutils等第三方包
slices.Contains 的基本用法与类型限制
它只支持可比较（comparable）类型的切片，比如 []int、[]string、[]bool，但不能用于含 map、func、slice 等不可比较元素的切片（例如 []map[string]int）。
- 正确示例：
slices.Contains([]string{"a", "b", "c"}, "b") // true - 错误示例：
slices.Contains([][]int{{1}, {2}}, []int{1})→ 编译失败，因为[]int不可比较 - 对结构体切片可用，但前提是结构体所有字段都可比较（无 slice/map/func 等）
- 性能上和手写 for 循环几乎一致，底层就是线性遍历，没有哈希优化
替代手写循环时的常见坑
很多人以为用了 slices.Contains 就“更安全”或“自动处理空切片”，其实它对空切片返回 false，这点和手写循环一致，但容易被忽略逻辑边界。
- 空切片行为：
slices.Contains([]int{}, 42)返回false，没问题，但如果你的业务里空切片应视为“全部匹配”或触发默认分支，就得额外判断 - 注意值语义：传入的是元素副本，对指针切片如
[]*T，比较的是指针地址，不是所指对象内容 - 没有自定义比较逻辑：无法像某些语言的
someArray.find(x => x.id === targetId)那样按字段匹配，必须提前投影成目标字段切片，或继续手写循环 - 不支持泛型约束外推：你不能用它检查
interface{}切片中的某个具体类型值，因为interface{}本身可比较，但运行时类型不匹配会导致恒为false
真正省事的地方只有一个：少写三行 for + if + return。但一旦涉及非 comparable 类型、字段级匹配、或需要索引位置，还是得回到 for 循环——别为了用而用。
