Go 三索引切片如何把容量限制传给下游

把切片交给下游函数时，最容易忽略的不是长度，而是容量。普通切片可能还带着一段调用方预留空间，下游一次 append 就有机会改写这段空间。Go 的三索引切片可以在传参前把容量“截断”：data[:len(data):len(data)] 的长度不变，但容量等于当前长度。这样下游继续追加时会得到新的底层数组。

三索引切片究竟把哪一段容量传下去了

普通写法 buf[low:high] 的容量会延伸到底层数组末端；三索引写法再增加一个 max，把容量终点明确设在这里。规范给出的计算很直接：结果长度为 high-low，结果容量为 max-low。

例如 buf[2:5:7] 的长度是 3、容量是 5。它依然与 buf 共享底层数组，位置 0 到 2 的元素也仍然可以被赋值。变化只发生在“还能向后扩展多少”这一项。

传给下游前，先把容量边界切到当前长度

如果调用方不希望下游追加内容时写入自己的预留区，可以在传参位置收紧容量：

package main

import "fmt"

// appendItem 只演示下游追加；返回值代表追加后新的切片描述符。
func appendItem(items []string) []string {
	return append(items, "downstream")
}

func main() {
	// len=2、cap=4，后面两格属于调用方的预留容量。
	buf := make([]string, 2, 4)
	buf[0], buf[1] = "a", "b"

	// 三索引表达式把 cap 从 4 收紧为 len，也就是 2。
	limited := buf[:len(buf):len(buf)]
	result := appendItem(limited)

	fmt.Println("before:", len(limited), cap(limited))
	fmt.Println("after:", len(result), cap(result))
	fmt.Println("caller:", buf)
}

在这个示例中，limited 的容量是 2。下游追加第三个元素时，已有容量不够，运行时会分配新的底层数组；result 能看到 downstream，调用方的 buf 不会因此多出这个元素。实际容量增长值由运行时决定，文章只依赖“必须脱离原容量”这个性质。

判断是否真的隔离：同时看 len、cap 和原切片

只打印追加后的结果还不够，因为 append 返回的是新的切片值。下游如果写成 append(items, x) 却不返回结果，调用方看不到长度变化；但在容量足够时，底层数组的元素仍可能已经被改写。三索引切片让“追加必分配”成为可控边界，不能替代返回值约定。

因此，接口边界可以采用一个简单约定：调用方把不应被下游扩写的切片先做 full slice expression；下游仍然可以修改当前元素，但新增元素必须通过返回值交还。

四个边界别写错

第一，索引必须满足 0 ，否则运行时会 panic。第二，max 不是“追加多少个元素”，而是底层数组中的容量终点。第三，三索引切片不会冻结已有元素；若要防止修改，需要复制数据或设计只读接口。第四，容量限制只影响从当前切片继续扩展的路径，不能阻止其他仍持有同一底层数组的切片修改数据。

常见问题

三索引切片会复制数据吗？

不会。它只创建新的切片描述符，仍共享原底层数组；只有后续追加超过受限容量时，才可能触发新的分配和复制。

为什么 append 后一定要接住返回值？

因为 append 可能返回指向新数组的切片，原来的切片变量不会自动更新长度、指针和容量。

把容量限制为长度后性能一定更好吗？

不一定。它换来的是边界更清楚和减少意外复用，但下游后续追加会更早分配；只有在隔离所有权比节省一次分配更重要时才值得这样做。

记住一句话即可：三索引切片不负责保护元素，它负责把“下游还能沿着同一底层数组追加多远”限定下来。