Contains 不能直接用 interface{} 实现，因为 []string 不是 []interface{} 的子类型，内存布局不同且 Go 不支持隐式转换；泛型需约束为 T comparable 才能安全使用 == 比较。
为什么 Contains 不能直接用 interface{} 实现
Go 在泛型出现前，很多人试图写一个接受 []interface{} 和 interface{} 的 Contains，结果发现：传入 []string 会编译失败。因为 []string 不是 []interface{} 的子类型——二者内存布局不同，Go 不做隐式转换。
泛型解决了这个问题，但代价是必须显式约束类型。最常见错误是直接写 func Contains[T any](s []T, v T) bool，看似通用，实则在比较时可能 panic（比如 T 是切片、map 或函数类型）。
-
T必须支持==操作，否则编译报错：invalid operation: cannot compare v == s[i] (operator == not defined for T) - Go 规定只有可比较类型（
comparable）才允许用==，所以参数约束必须是T comparable - 如果真要支持不可比较类型（如
struct含 slice 字段），得换用reflect.DeepEqual，但性能差、无编译期检查
Contains 的标准泛型写法（推荐）
用 comparable 约束是最平衡的选择：安全、高效、符合直觉。几乎所有内置类型（int, string, bool, 指针，甚至自定义 struct 只要字段都可比较）都能用。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func Contains[T comparable](s []T, v T) bool {
for _, item := range s {
if item == v {
return true
}
}
return false
}
- 调用时无需显式指定类型：
Contains([]string{"a", "b"}, "a")自动推导T = string - 若传入含 map 字段的 struct，编译直接报错，比运行时 panic 更早暴露问题
- 注意：空切片返回
false，这是合理行为，不是 bug
需要支持不可比较类型的场景怎么办
比如你要查一个 []struct{ Name string; Tags []string } 中是否存在某个 Tags 完全相等的元素。这时 comparable 不够用，只能退到运行时比较。
- 别自己手写
reflect.DeepEqual循环——容易漏指针、chan、func 等不可比较字段，且性能差 - 更稳妥的做法是：让调用方传入比较函数，把控制权交出去：
func ContainsBy[T any](s []T, f func(T) bool) bool - 示例：
ContainsBy(users, func(u User) bool { return u.Name == "Alice" && len(u.Tags) == 2 }) - 这种写法不依赖
==，也不强制要求T可比较，灵活性高，但每次调用都要写逻辑
别忽略的细节：切片为空、nil、或底层为 nil
Go 切片可以是 nil，也可以是非 nil 但长度为 0（比如 make([]int, 0)）。这两种情况对 range 都安全，但有人会误加 if s == nil 判断，其实没必要。
-
for range nil不 panic，直接跳过循环体，返回false - 但如果你用了
len(s)做前置判断，记得：空切片和 nil 切片的len都是 0，无法区分 - 真正需要区分 nil 和空的情况极少；大多数业务逻辑里，两者语义一致（“没有元素”）
- 如果硬要区分，用
if s == nil，但别把它塞进Contains主逻辑——那是调用方该决定的事
泛型 Contains 的核心就两点：用 comparable 约束守住安全边界，用 range 遍历保持简洁。其余所有“更通用”的需求，基本都在牺牲可读性或性能，得看具体场景值不值得。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
