Go slices.Move 新提案：一次搬动，胜过两次删除插入

原创

go
go

Go语言教程

2026年7月27日 13:30
陕西

在小说阅读器读本章

去阅读

Go slices.Move 新提案：一次搬动，胜过两次删除插入

job := queue[from]
queue = slices.Delete(queue, from, from+1)
queue = slices.Insert(queue, to, job)

这三行代码我写过不止一次。

任务优先级变了，把它往前挪；菜单顺序调整，把某一项拖到后面；内存里维护一份有序连接列表，权重更新后重新找位置。

功能没问题，代码看着也挺 Go。

但我每次看到这段写法都有点别扭：切片长度从头到尾没变，只是移动一个元素，为什么非得先删除，再插入？

Go 社区最近提了一个 slices.Move，就是冲着这个小别扭来的。截至 2026 年 7 月 10 日，这个提案仍处于 Open 状态，还没有进入标准库；当前 slices 包的公开 API 里也找不到 Move。

提议的调用方式很直接：

slices.Move(queue, from, to)

把 from 位置的元素搬到 to，中间那段元素整体平移，切片长度不变。

这事看着小，底下差别不小。

上面的删除加插入，Delete 要把后半段向前复制，还会清理失效的尾部元素；紧接着 Insert 又把目标位置之后的数据向后挪，为刚才删除的元素腾位置。Go 当前的 slices.Delete 和 slices.Insert 源码确实分别包含数据复制逻辑，删除时还会对废弃区域执行 clear。

一个元素搬家，前后搬了两轮。

Move 的处理更干脆：先暂存目标元素，中间区域只平移一次，再把暂存值写回目标位置。提案给出的理由也是减少一次重叠区域的内存搬动，由两次变成一次。

标准库还没提供，我会先在项目内部放一个小函数：

func moveAt[S ~[]E, E any](items S, from, to int) {
 if uint(from) >= uint(len(items)) || uint(to) >= uint(len(items)) {
  panic(\"moveAt: index out of range\")
 }
 if from == to {
  return
 }

 picked := items[from]

 switch {
 case from < to:
  copy(items[from:to], items[from+1:to+1])
 case from > to:
  copy(items[to+1:from+1], items[to:from])
 }

 items[to] = picked
}

这里我故意不返回切片。

因为长度没变，底层数组也没换，返回一个新的 slice header 反而容易让调用方误以为发生了扩容或者重新分配。这个函数做的就是原地调整顺序，语义应该写在脸上。

比如队列原来是这样：

type Task struct {
 ID       string
 Priority int
}

tasks := []Task{
 {ID: \"sync-stock\", Priority: 90},
 {ID: \"send-mail\", Priority: 70},
 {ID: \"make-report\", Priority: 40},
 {ID: \"clear-cache\", Priority: 20},
}

moveAt(tasks, 3, 1)

执行以后，clear-cache 被放到索引 1，原来索引 1 到 2 的任务依次后移：

sync-stock
clear-cache
send-mail
make-report

从后往前挪也是同一套逻辑：

moveAt(tasks, 0, 2)

原来第一个任务会落到索引 2，它后面的元素整体向前补位。

这里有个边界容易写错：to 表示移动完成后的最终索引，不是删除元素之后临时切片里的插入坐标。

删除加插入时，只要 from < to，删除动作就会让后面的索引整体减一。代码里经常会冒出这种补丁：

picked := tasks[from]
tasks = slices.Delete(tasks, from, from+1)

if from < to {
 to--
}

tasks = slices.Insert(tasks, to, picked)

这种代码短是短，过两个月再看，我得重新推一遍索引。更麻烦的是，某个调用方做了 to--，另一个调用方没做，同一个“移动”操作能写出两套语义。

Move 真正值钱的地方不只是少一次 copy，而是把这套索引规则收进一个明确的 API。

当然，也别看到“一次 memmove”就急着给所有项目换。

切片只有十几个元素，移动操作一天跑不了几次，性能差别基本不值得专门讨论。真正适合它的是长切片上的频繁重排：优先队列快照、排行榜缓存、调度列表、按权重维护的节点集合，或者某个排序字段更新后，只调整单个元素的位置。

这种场景每次都全量排序太重，删除再插入又多搬一次。Move 正好卡在中间：不重新分配，不改变长度，只动必须动的那一段。

这个提案不大，甚至小得不像一个新 API。

但标准库里好用的函数往往就是这样。它没有发明新能力，只是把大家反复写、容易写歪、还能少做一次内存搬动的操作，收成一个名字。

Move，比 Delete 完再 Insert，确实顺手。