slices Delete 与 DeleteFunc 后如何避免保留引用

我第一次把 Go 的切片删除代码换成 slices.Delete，关注点只放在“元素有没有少”。后来排查一个长生命周期缓存时才发现，切片长度变短并不等于底层数组里的每个槽位都不再持有对象。更稳妥的做法是：删除后接住返回值，并让删除函数负责把缩短后留下的尾部槽位清零。

如果元素包含指针、字符串、切片、map、函数或接口等引用，优先使用 slices.Delete / slices.DeleteFunc，并始终写成 s = slices.Delete(...)。标准库会清理缩短区间对应的尾部元素；但仍要留意其它切片、缓存或变量是否保留着同一对象。

本文只讨论删除后的尾部清零和引用释放，不展开并发切片，也不把静态说明图当成运行截图。

先分清两种删除：区间和条件

slices.Delete(s, i, j) 删除的是半开区间 s[i:j]，适合已经知道下标的连续区域；slices.DeleteFunc(s, del) 则保留判断函数返回 false 的元素，适合按状态、类型或业务条件批量过滤。

package main

import (
    "fmt"
    "slices"
)

func main() {
    jobs := []string{"queued", "expired", "running", "expired", "done"}

    // 删除已知下标的区间，结果必须接回原变量。
    jobs = slices.Delete(jobs, 1, 2)

    // 按条件删除所有过期任务，同样接住返回的切片头。
    jobs = slices.DeleteFunc(jobs, func(job string) bool {
        // 这里只表达筛选条件，不在回调里修改 jobs 本身。
        return job == "expired"
    })

    fmt.Println(jobs)
}

两种函数都会修改原底层数组并返回新的切片头。只调用函数而不赋值，原变量的 len 仍然是旧值，后续遍历就可能把已经逻辑删除的槽位继续当成有效元素。

长度变短，底层数组并不会凭空消失

切片本质上是指向底层数组的一小段描述。删除后返回的切片长度变小，但容量和底层数组是否继续存在，取决于是否还有切片头、字段或其它变量引用它。对普通值类型来说，尾部残留通常只是旧值；对包含引用的元素来说，旧值可能继续指向大对象。

标准库文档明确说明，Delete 会把缩短后尾部对应的元素清零，DeleteFunc 会把新长度到原长度之间的元素清零。这个动作的意义不是改变返回切片的可见内容，而是让底层数组不再因为这些无效槽位继续持有引用。

package main

import (
    "fmt"
    "slices"
)

type Record struct {
    Name string
    Data *[]byte
}

func main() {
    a := []byte("large payload")
    b := []byte("temporary payload")
    records := []Record{
        {Name: "keep", Data: &a},
        {Name: "drop", Data: &b},
    }

    // Delete 会移动保留元素，并清零缩短后留下的尾部槽位。
    records = slices.DeleteFunc(records, func(r Record) bool {
        // 根据业务标记删除，不在这里手动操作底层数组。
        return r.Name == "drop"
    })

    // 这里的长度代表逻辑数据；其它别名仍可能继续持有底层数组。
    fmt.Println(len(records), records[0].Name)
}

因此，“使用 Delete 就绝对不会有内存问题”并不是正确结论。它只负责删除操作本身的尾部清零；如果还有一个长期保存的别名切片、缓存字段或单独变量指向同一对象，那个引用仍然有效。

我现在会把删除写成一个完整的生命周期边界

在实际代码里，我会把四件事放在同一个小函数中：明确输入切片的所有权，选择区间或条件删除，接住返回值，再确认是否还有需要保留的别名。这样比在很多调用点散落手写 append(s[:i], s[j:]...) 更容易维护。

package main

import "slices"

type Item struct {
    Key   string
    Cache map[string]string
}

func removeTemporary(items []Item) []Item {
    // DeleteFunc 负责移动保留项，并清零尾部的 Item 槽位。
    items = slices.DeleteFunc(items, func(item Item) bool {
        // 只删除临时项；回调不保存 item 的地址，避免制造额外引用。
        return item.Key == "temporary"
    })

    // 返回新的切片头，让调用方看到正确的长度。
    return items
}

func removeRange(items []Item, from, to int) []Item {
    // 调用方应保证区间合法；Delete 对越界区间会 panic。
    return slices.Delete(items, from, to)
}

如果业务还要释放元素内部持有的外部资源，例如文件、连接或自定义句柄，不能把“切片尾部清零”和“业务资源关闭”混为一谈。清零只会把元素槽位改成零值，不会替你调用 Close、提交事务或清理外部系统状态。

几个容易踩到的边界

• 忘记接返回值：删除函数返回的是新的切片头，原变量不会自动缩短。
• 把容量当成长度：容量更大不代表尾部元素仍是业务数据，也不代表其它别名已经失效。
• 手写 append 删除：如果必须兼容旧实现，删除引用元素后要按同样的生命周期思路清零尾部槽位。
• 误解清零范围：清零的是缩短后留下的尾部元素，不是把所有数组内容都清零。

相关问题

DeleteFunc 会分配新数组吗？它会原地修改输入切片并返回修改后的切片；是否发生其它分配不应靠标题猜测，应该以具体代码和运行环境的测量结果为准。

删除后还需要手动把尾部设为 nil 吗？使用标准 Delete 或 DeleteFunc 时，文档规定的缩短尾部清零已经由函数完成；只有手写等价逻辑时，才需要自己补上相同的清理责任。

我的经验是：把“接住返回切片”和“释放无效引用”视为同一个删除动作。这样既能让逻辑长度正确，也能让长生命周期的数据结构少保留一份不再需要的对象引用。