Go slices 包删除元素并处理底层引用的内存边界

我在整理一段需要批量移除记录的 Go 代码时，最容易误判的不是“怎么删”，而是删完以后底层数组还保留了什么。结论很明确：连续区间优先写成 s = slices.Delete(s, i, j)，把 [i,j) 交给标准库处理；不要忽略返回值，也不要把“切片长度变短”理解成底层引用已经自动消失。

官方文档：https://pkg.go.dev/slices

当前 Go 版本的 slices.Delete 会在原地移动后清零新长度之外的尾部元素。对包含指针、字符串、切片、map、channel 或 interface 的元素，这个清零动作能避免已经删除的对象仅因为底层数组残留而继续保持可达；但它不会替你处理别的别名切片。

先确认 slices.Delete 改的是共享底层数组

slices.Delete 的签名是 Delete(s, i, j)。它删除 s[i:j]，把后面的元素向左移动，再返回长度缩短后的切片。只要容量允许，通常不需要分配新的底层数组，所以这个调用不是“复制一份新切片再删除”。

这也是为什么它必须返回切片：切片描述符里的长度变了，而调用方手里的描述符不会被函数按引用改写。底层数组可能已经改变，但变量 s 的长度仍是旧值，直到你接收结果。

用返回值覆盖原切片，避免两个常见误判

下面的示例只表达 API 关系，不代表现场运行截图。注释保留了边界判断和资源无关的关键逻辑：

package main

import (
    "fmt"
    "slices"
)

func main() {
    records := []string{"keep-a", "drop-a", "drop-b", "keep-b"}

    // [1,3) 只删除下标 1 和 2，右端下标 3 不包含在范围内。
    records = slices.Delete(records, 1, 3)

    // Delete 会改动底层数组，返回值同时更新长度和可见元素范围。
    fmt.Println(records) // [keep-a keep-b]
}

第一种错误是只调用 slices.Delete(records, 1, 3)，却继续使用旧的 records。第二种错误是写成 trimmed := slices.Delete(records, 1, 3)，随后又把 records 当作未变化的旧数据使用。若旧变量还有业务意义，应明确说明它已经指向被修改过的底层存储，而不是把它当快照。

尾部清零解决的是“不可见引用仍存活”

删除后，返回切片的长度已经变短，但原底层数组的容量可能仍然更大。Go 官方在 Go 1.22 的泛型切片函数调整中明确了 Delete 的尾部清零：新长度之后的元素会被置为元素类型的零值。对于 *Image、含指针字段的结构体、字符串或 interface，这意味着已经不在结果中的引用不会仅因为底层数组残留而继续维持对象可达。

这里要区分两个概念：清零尾部有助于垃圾回收，不能缩小数组本身，也不会让仍被其他切片、map 或业务缓存持有的对象立刻消失。若必须彻底隔离大数组，可以根据生命周期选择复制到新切片；如果只是删除一段记录，先使用标准 API 并正确接收返回值即可。

连续删除一次完成，别在循环里反复搬移

官方文档给出的复杂度是 O(len(s)-i)。当要删除的是一个连续区间，建议先算出稳定的起止下标，再一次调用 slices.Delete。循环从前往后逐个删除，会反复移动后缀元素，也更容易因为下标变化漏删或跳过记录。

如果输入来自不可信下标，先做范围检查；文档规定 j > len(s) 或 s[i:j] 无效时会 panic。空区间 i == j 不会删除元素，但仍应让调用方的意图清楚。

常见问题

为什么 slices.Delete 后还要写等号？

因为函数返回的是长度已经变化的新切片描述符。底层数组可能原地修改，但原变量的长度不会自动更新。

删除指针元素后容量还很大，算内存泄漏吗？

不一定。容量大表示底层数组仍可复用；当前 slices.Delete 会清零结果尾部的引用。只有在大数组本身仍被长期持有、或其他别名仍保留对象时，才需要进一步复制或调整数据生命周期。

能不能用 append 代替 slices.Delete？

可以表达同类搬移，但区间语法更容易写错，还要自行考虑指针尾部清零。新代码优先使用标准库 API，并把返回值赋回原变量。