go 中 slice 虽是引用类型，但其本身（指针+长度+容量）按值传递；直接在函数内对 slice 调用 append 或切片操作后未赋值回原变量，会导致原 slice 头信息失效，进而引发底层数组意外共享和重复覆盖。
go 中 slice 虽是引用类型，但其本身（指针+长度+容量）按值传递；直接在函数内对 slice 调用 append 或切片操作后未赋值回原变量，会导致原 slice 头信息失效，进而引发底层数组意外共享和重复覆盖。
在 Go 中，slice 并非传统意义上的“引用类型”，而是一个包含三个字段的结构体：指向底层数组的指针、当前长度（len）和容量（cap）。当将 slice 作为参数传入函数时，传递的是该结构体的副本——即值传递。这意味着函数内部可以修改底层数组的元素（因指针相同），但若通过 append 或切片操作改变了 slice 的指针、len 或 cap，这些变更不会自动反映到调用方的原始 slice 变量上，除非显式赋值。
你遇到的异常输出 [40 50 50 50 50] 正源于此机制：
- 初始 test.testArray = []float64{10,20,30,40,50}，底层数组为 [10 20 30 40 50]，cap=5；
- testFunction(test.testArray) 接收其副本 array，初始指向同一底层数组；
- 每次调用 removeFrom(array, 0) 执行 append(array[:0], array[1:]...)：
- 第一次：array[:0] 是空 slice（len=0），array[1:] 是 [20 30 40 50] → append 后得到 [20 30 40 50]，可能复用原底层数组（cap 足够）；
- 第二次：array 变为 [20 30 40 50]，removeFrom 后得 [30 40 50]；
- 第三次：array 变为 [30 40 50]，但此时 array[:0] 和 array[1:] 共享同一底层数组片段，append 在原数组位置 [30 40 50 ? ?] 上写入 [40 50]，由于容量未超限，append 直接覆写前两个位置，而后续未初始化的元素仍保留旧值（50 被多次复制），最终导致 test.testArray 的底层数组被意外修改为 [40 50 50 50 50]。
✅ 正确做法：始终将 append 或切片操作的结果重新赋值给 slice 变量，并在需要时将结果返回给调用方：
func testFunction(array []float64) []float64 {
for i := 0; i < 3; i++ {
array = removeFrom(array, 0) // 关键：必须赋值！
}
fmt.Println(array)
return array // 显式返回新 slice
}
func main() {
fmt.Println(test.testArray) // [10 20 30 40 50]
result := testFunction(test.testArray)
fmt.Println(result) // [40 50]
fmt.Println(test.testArray) // [10 20 30 40 50] —— 未被修改！
}⚠️ 注意事项：
- 不要依赖 append 是否触发扩容：小容量 slice 的 append 常复用原底层数组，造成隐蔽副作用；
- 若需就地修改原始 slice（如更新 struct 字段），应传入 slice 指针：func testFunction(array *[]float64)，并在内部使用 *array = removeFrom(*array, 0)；
- 对于只读场景，可直接使用 array[i:] 等切片语法，避免 append 引发的不确定性；
- 使用 fmt.Printf("%p %d %d\n", unsafe.Pointer(&array[0]), len(array), cap(array)) 可验证 slice 头是否变化。
总结：Go 的 slice 设计兼顾性能与可控性，但要求开发者明确管理 slice 头的生命周期。牢记 “每次 append 或切片后，务必赋值”，是避免此类“诡异行为”的黄金法则。
