借助类型参数，我们可以为所有类型的切片编写像slices.Index这样的函数：
// Index 返回s中v首次出现的索引，
// 如果不存在，则返回-1。
func Index[S ~[]E, E comparable](s S, v E) int {
for i := range s {
if v == s[i] {
return i
}
}
return -1
}不再需要为每种不同类型的元素再次实现Index。
slices包包含许多这样的助手函数，用于对切片执行常见操作：
s := []string{"Bat", "Fox", "Owl", "Fox"}
s2 := slices.Clone(s)
slices.Sort(s2)
fmt.Println(s2) // [Bat Fox Fox Owl]
s2 = slices.Compact(s2)
fmt.Println(s2) // [Bat Fox Owl]
fmt.Println(slices.Equal(s, s2)) // false一些新函数（Insert、Replace、Delete等）修改切片。要了解它们是如何工作的，以及如何正确使用它们，我们需要检查切片的底层结构。
切片是数组一部分的视图。在内部，切片包含一个指针、一个长度和一个容量。两个切片可以有相同的底层数组，并且可以查看重叠的部分。
例如，这个切片s是对大小为 6 的数组中 4 个元素的视图：
如果函数更改了作为参数传递的切片的长度，则需要将新的切片返回给调用者。如果不需要增长，底层数组可能保持不变。这解释了为什么append和slices.Compact返回一个值，但slices.Sort，仅重新排序元素，不返回值。
考虑删除切片一部分的任务。在泛型出现之前，从切片s中删除部分s[2:5]的标准方法是调用append函数将结尾部分复制到中间部分：
s = append(s[:2], s[5:]...)语法复杂且容易出错，涉及到子切片和可变参数。我们添加了slice.Delete来简化元素的删除：
func Delete[S ~[]E, E any](s S, i, j int) S {
return append(s[:i], s[j:]...)
}一行函数Delete更清晰地表达了程序员的意图。考虑长度为 6、容量为 8 的切片s，包含指针：
这个调用从切片s中删除了s[2]、s[3]、s[4]的元素：
s = slices.Delete(s, 2, 5)通过向左移动元素s[5]来填补索引 2、3、4 处的空隙，并将新的长度设置为3。
Delete不需要分配新数组，因为它就地移动元素。像append一样，它返回一个新切片。slices包中的许多其他函数也遵循这种模式，包括Compact、CompactFunc、DeleteFunc、Grow、Insert和Replace。
调用这些函数时，我们必须认为原始切片无效，因为底层数组已经被修改。调用函数但忽略返回值将是一个错误：
slices.Delete(s, 2, 5) // 不正确！
// s的长度仍然相同，但内容被修改了不希望的生存期问题
在 Go 1.22 之前，slices.Delete并没有修改新旧切片长度之间的元素。虽然返回的切片不包括这些元素，但在原始的、现在无效的切片的末尾创建的“空隙”继续保留它们。这些元素可能包含指向大对象（20MB 图像）的指针，垃圾收集器不会释放与这些对象关联的内存。这导致内存泄漏，可能导致严重的性能问题。
在上述示例中，我们成功地从s[2:5]中删除了指针p2、p3、p4，通过将一个元素向左移动。但是p3和p4仍然存在于底层数组中，超出s的新长度。垃圾收集器不会回收它们。更不明显的是，p5不是被删除的元素之一，但是由于数组灰色部分保留的p5指针，其内存可能仍然泄漏。
对于开发者来说，如果他们不知道“不可见”的元素仍在占用内存，这可能会令人困惑。
因此，我们有两个选择：
• 保持Delete的高效实现。如果用户想确保指向的值可以被释放，让用户自己将过时的指针设置为nil。
• 或者更改Delete，始终将过时的元素设置为零。这是额外的工作，使得Delete稍微效率低一些。将指针置零（设置为nil）可以在它们变得不可达时启用对象的垃圾收集。
哪个选项最好并不明显。第一个默认提供性能，第二个默认提供内存节俭。
解决方案
一个关键观察是，“将过时的指针设置为nil”并不像看起来那么容易。事实上，这项任务是如此容易出错，以至于我们不应该让用户承担编写它的负担。出于实用主义，我们选择修改Compact、CompactFunc、Delete、DeleteFunc、Replace五个函数的实现，以“清除尾部”。一个好的副作用是，认知负担减少了，用户现在不需要担心这些内存泄漏了。
在 Go 1.22 中，调用 Delete 后，内存看起来像这样：
五个函数中的代码改动使用了新的内置函数clear（Go 1.21）将过时元素设置为s元素类型的零值：
当E是指针、切片、映射、通道或接口的类型时，E的零值是nil。
测试失败
这一变化导致了一些在 Go1.21 中通过的测试在 Go 1.22 中失败，当切片函数被不正确使用时。这是个好消息。当你有一个 bug 时，测试应该让你知道。
如果你忽略了Delete的返回值：
slices.Delete(s, 2, 3) // !! 不正确 !!那么你可能错误地假设s不包含任何 nil 指针。在 Go Playground 中的示例。
如果你忽略了Compact的返回值：
slices.Sort(s) // 正确
slices.Compact(s) // !! 不正确 !!那么你可能错误地假设s已正确排序并压缩。示例。
如果你将Delete的返回值分配给另一个变量，并继续使用原始切片：
u := slices.Delete(s, 2, 3) // !! 不正确，如果你继续使用s !!那么你可能错误地假设s不包含任何 nil 指针。示例。
如果你意外地遮蔽了切片变量，并继续使用原始切片：
s := slices.Delete(s, 2, 3) // !! 不正确，使用:=而不是= !!那么你可能错误地假设s不包含任何 nil 指针。示例。
结论
slices包的 API 相比传统的预泛型语法来删除或插入元素有所改进。
我们鼓励开发者使用新函数，同时避免上述列出的“陷阱”。
得益于最近实现的变更，一类内存泄漏被自动避免，无需对 API 进行任何更改，也不需要开发者做额外工作。
