修改 slice 底层数组元素可直接操作，但改变 len 或 cap 必须返回新 slice 并由调用方重新赋值；使用 *[]T 不仅无法可靠解决底层数组更换问题，还易引发 data race 和不可预测行为。
修改 slice 底层数组必须通过原 slice 变量赋值，不能靠函数参数“传指针”
Go 中的 slice 本身是值类型，包含三个字段：ptr（指向底层数组的指针）、len、cap。虽然它内部有指针，但整个 slice 结构体是按值传递的。所以你在函数里对形参 s 做 s[i] = x 能改到底层数组，但做 s = append(s, x) 或 s = s[1:] 就只改了副本，调用方看不到变化。
常见错误现象：写了个 addOne(s) 函数想给 slice 末尾加元素，结果原 slice 没变；或者写了 reset(s) 想清空内容，发现只是把形参重置了。
- 要修改底层数组元素（如
s[0] = 100），直接操作即可，无需额外手段 - 要改变
len或cap（如append、切片操作、重分配），必须返回新slice并由调用方重新赋值 - 不要试图用
*[]T来“绕过”这个问题——这只会让代码更难懂，且无法解决append可能导致底层数组更换的问题
append 后原 slice 可能失效：底层数组可能已更换
append 是否复用原底层数组，取决于当前 len 和 cap。当 len == cap 时，append 必须分配新数组，此时原 slice 的 ptr 指向的内存未变，但新 slice 指向了另一块内存。如果多个 slice 共享同一底层数组（比如通过 s[2:4] 切出来的），append 一个后，其他 slice 仍指向旧数组，数据不再同步。
典型场景：你有一个大 []byte 缓冲区，反复切出子 slice 处理，又在某个子 slice 上 append —— 这会悄悄触发扩容，后续再读原缓冲区就看不到这次写入。
立即学习“go语言免费学习笔记（深入）”；
- 检查是否扩容：比较
cap(s)和cap(newS)，不等说明底层数组已换 - 避免意外共享：若需独立操作，用
copy(dst, src)显式复制一份，而不是依赖切片 - 调试时可打印
&s[0]（注意 panic 风险，确保len > 0）来观察地址是否变化
如何安全地在函数中修改 slice 长度和内容
最稳妥的方式是让函数返回新 slice，并强制调用方更新变量。这是 Go 标准库（如 strings.Builder.Grow、bytes.Buffer.Write）也遵循的模式。
func addInt(s []int, x int) []int {
return append(s, x)
}
func trimFirst(s []string) []string {
if len(s) == 0 {
return s
}
return s[1:]
}
// 使用：
data := []int{1, 2}
data = addInt(data, 3) // 必须重新赋值
data = trimFirst(data) // 同样必须
如果函数逻辑复杂、涉及多次 append 或切片，依然适用该模式。不要为了“省一次赋值”而引入 *[]T 或全局状态。
- 返回
[]T是明确、无副作用、符合 Go 习惯的做法 - 编译器能优化掉大部分返回值拷贝（仅拷贝 header，不是整个底层数组）
- 如果函数还需返回其他信息（如 error），就用多返回值：
func do(s []byte) ([]byte, error)
为什么 *[]T 几乎没用，还容易引发 bug
有人觉得“既然 slice 有指针，那传 *[]T 就能修改长度”，但这是误解。*[]T 是指向 slice header 的指针，改它确实能让函数内 *s = append(*s, x) 影响调用方变量——但前提是底层数组没换。一旦 append 触发扩容，*s 指向的新 header 里的 ptr 指向新内存，而其他共享该底层数组的 slice 仍指向旧内存，行为变得不可预测。
更麻烦的是：如果你把 *[]T 传给多个函数，或在 goroutine 里并发修改，极易出现 data race，因为多个地方在写同一个 header 地址，且没有同步机制。
-
*[]T唯一合法用途是初始化前的 nil slice 构造（如var s *[]int; *s = make([]int, 0)），但通常直接用s := make([]int, 0)更清晰 - 标准库、知名项目（如
golang.org/x/exp/slices）全部采用返回新 slice 的方式 - IDE 和 vet 工具不会警告
*[]T的误用，但 runtime 可能因内存错位静默出错
真正需要“可变 slice 参数”的场景极少，绝大多数时候，老老实实返回新 slice，是最小认知负担、最高可维护性的选择。
