Go slices.Compact 清理重复值时为什么还要处理尾部

先说结论：slices.Compact 清掉的是连续重复值，它会在原切片的底层数组上完成压缩，然后把新长度之后的尾部元素清零。尾部虽然不再属于返回值的 len 范围，但对指针、字符串和含引用字段的元素来说，仍可能让旧对象保持可达。

一、先确认 Compact 处理的是连续重复值

例如输入 []int{2, 2, 3, 2, 4, 4}，结果应是 []int{2, 3, 2, 4}。开头的两个 2 和结尾的两个 4 各自只保留一个，但中间再次出现的 2 不会被删除。这个语义决定了它适合清理已经排序、分组或相邻重复的记录流，不适合替代基于 map 的全局去重。

package main

import (
    "fmt"
    "slices"
)

func main() {
    // Compact 只合并相邻重复值，不改变不同值之间的顺序。
    values := []int{2, 2, 3, 2, 4, 4}
    values = slices.Compact(values)
    fmt.Println(values) // 预期： [2 3 2 4]
}

二、沿着 k 和 s2 看压缩过程

实现第一次发现重复值后，把当前位置记为 k，再从 s2 := s[k:] 中寻找下一段不重复的元素。找到后执行 s[k] = s2[k2]，并递增 k。因此它修改的是原数组，而不是自动创建一份完全独立的结果。

这也是调用时必须写成 values = slices.Compact(values) 的原因：返回值的长度可能变小。若只调用 slices.Compact(values) 而丢掉返回值，变量仍然保留旧长度，后续循环就会把尾部当成有效数据。

三、尾部清理解决的是旧引用存活

源码在返回 s[:k] 前执行 clear(s[k:])。这里的重点不是把整数尾部“擦干净”，而是处理元素内部可能存在的引用。例如 []*Record 中，被压缩掉的记录指针如果还留在底层数组尾部，垃圾回收器仍可能把它当作可达引用。清零后，这些无效槽位不再继续指向旧对象。

因此，“新切片长度变短”和“旧底层数组尾部被清理”是两个不同动作：前者改变调用者看到的有效范围，后者处理范围之外的引用生命周期。对 []int 来说，尾部清零通常只是语义上的整洁；对指针或复合引用元素来说，它可能直接影响长期运行程序的内存占用。

四、按元素类型和容量决定是否复用结果

可以用下面的清单做收尾检查：

• 输入是否已经按业务键分组？如果不是，Compact 不会做全局去重。
• 是否接住返回值，并只按新的 len 访问？
• 元素是否含指针、字符串、切片、map、函数或接口等引用？这类元素更需要理解尾部清理。
• 是否还有旧切片别名？如果有，不要把它当成压缩后的独立快照。
• 后续是否要跨边界保存数据？需要隔离底层数组时，用 slices.Clone 或显式复制。

相关问题

slices.Compact 和 map 全局去重有什么区别？

Compact 只看相邻元素，保留每段连续重复值的第一个；map 去重才会跨越位置记录已经见过的值。

为什么不能忽略 Compact 的返回值？

因为返回值携带新的有效长度。忽略它会让原变量继续以旧长度读取已经失效的尾部。

清理尾部是不是代表底层数组被释放了？

不是。切片仍可能复用原底层数组；清零只是解除尾部元素中的引用，是否释放还取决于其他引用和数组生命周期。