go 1.21+ 应直接导入标准库 "slices"，旧版本才需 go get golang.org/x/exp/slices；slices.sort 泛型安全，sort.slice 依赖反射易 panic；结构体排序需用 slices.sortfunc，去重查找需 indexfunc 或手写逻辑；无 filter/map，推荐显式 for 循环。
为什么不能直接用 slices 包而报 “cannot find package”
Go 1.21+ 才正式将 x/exp/slices 中的大部分函数移入标准库 slices（无 x/exp/ 前缀），但很多人仍按旧文档写 golang.org/x/exp/slices，结果构建失败。如果你用的是 Go ≥ 1.21，应该直接导入 slices；若用的是 Go 1.20 或更早，才需手动 go get golang.org/x/exp/slices，且必须注意该包处于 experimental 状态，API 可能变动。
常见错误现象：build: cannot find module providing package golang.org/x/exp/slices 或 undefined: slices.Sort（实际已导入但版本不匹配）。
- Go 1.21+：用
import "slices"，无需额外安装 - Go 1.20 及以下：运行
go get golang.org/x/exp/slices，然后import "golang.org/x/exp/slices" - 检查 Go 版本：运行
go version，别只看 IDE 显示的 SDK 路径
slices.Sort 和 sort.Slice 的关键区别在哪
slices.Sort 是泛型安全的，编译期检查元素类型是否支持比较；sort.Slice 是反射实现，运行时才校验，且容易因字段名拼错或类型不兼容 panic。
例如对 []string 排序：
// ✅ 安全、简洁、泛型推导自动完成
slices.Sort(strs)
// ❌ 需手写 Less 函数，易出错，且不校验 strs 是否可排序
sort.Slice(strs, func(i, j int) bool { return strs[i]
-
slices.Sort要求元素类型实现constraints.Ordered（如int,string,float64），否则编译报错：cannot use … as type constraints.Ordered - 自定义结构体排序？必须自己实现
Less函数，并用slices.SortFunc，不是slices.Sort -
slices.Sort内部复用sort.Slice，性能几乎一致，但多了类型安全层
如何对自定义结构体切片做去重或查找
slices 包里没有 Unique，也没有 Contains（针对非 Ordered 类型）。别硬套 slices.Contains——它只接受 Ordered 类型参数，结构体默认不满足。
正确做法分两步：先确认是否能用泛型约束，再选函数。
- 查找结构体：用
slices.IndexFunc+ 自定义谓词，例如slices.IndexFunc(users, func(u User) bool { return u.ID == 123 }) - 去重结构体：没有内置函数，需手写循环 +
map记录已见 key（如map[int]bool存 ID），或用slices.CompactFunc（Go 1.21.0 后支持，要求相邻重复项被识别） -
slices.Equal可用于结构体切片，但前提是元素类型支持==（即所有字段都可比较），否则编译失败
哪些操作仍然得回退到 for 循环或 filter 模式
slices 包刻意保持精简，不提供类似 JavaScript 的 map / filter 泛型函数。官方认为这类操作逻辑耦合度高，用 for 更清晰、更可控，也避免隐式分配。
比如想筛选出价格 > 100 的商品：
// ✅ 推荐：明确、无隐藏分配、可提前 break
var expensive []Product
for _, p := range products {
if p.Price > 100 {
expensive = append(expensive, p)
}
}
// ❌ 不要期待 slices.Filter（不存在）
// expensive := slices.Filter(products, func(p Product) bool { return p.Price > 100 })
-
slices.DeleteFunc可删除满足条件的元素，但它会“收缩”原切片（修改底层数组），注意别在循环中直接用，否则跳过元素 - 需要转换（map）场景？Go 社区普遍接受显式
for，而不是引入第三方泛型工具包 - 如果真需要链式调用风格，考虑
lo（github.com/samber/lo），但它不属于标准路径，需权衡依赖成本
泛型切片操作的边界很清晰：排序、查找、比较、基本变换有对应函数；但涉及元素映射、条件投影、复杂聚合时，Go 依然选择把控制权交还给开发者——不是功能缺失，而是设计取舍。最容易被忽略的是，以为 slices 能覆盖所有 JS 式数组方法，结果卡在 Filter 上查半天文档。
