根本原因在于slice是值传递的结构体，修改元素影响原数组，但append扩容只改变副本的ptr；需传*[]T才能使扩容生效。
为什么修改切片内容有时不生效，有时却能影响原切片？
根本原因在于：Go 中所有参数都是值传递，但 slice 类型本身是一个包含 ptr（底层数组地址）、len 和 cap 的结构体。传参时复制的是这个结构体，不是底层数组——所以修改元素（如 s[i] = x）会反映到原数组，但若在函数内用 append 导致扩容，新底层数组地址会写入副本的 ptr 字段，原 slice 结构体不受影响。
- 想让扩容也影响调用方？必须传
*[]T（指向切片的指针） - 只读遍历或原地修改元素？直接传
[]T足够，无额外开销 - 误以为
append后原切片变长，是常见调试陷阱；可加fmt.Printf("cap=%d, len=%d, ptr=%p", len(s), cap(s), &s[0])验证
什么时候该用 *[]int 而不是 []int？
仅当函数需要「可能改变调用方持有的切片头信息」时才需指针。典型场景是：函数内部逻辑不确定是否扩容，且调用方必须拿到新长度/容量/底层数组地址。
- 常见于构建工具链、序列化器、或封装
bufio.Scanner类似行为的函数 - 示例：一个解析多行输入并累积结果的函数，每行可能触发
append扩容，最终必须返回完整数据 - 性能上，
*[]T多一次内存解引用，但比起底层数组拷贝，几乎可忽略；真正代价来自扩容本身
func parseLines(r io.Reader, lines *[]string) error {
sc := bufio.NewScanner(r)
for sc.Scan() {
*lines = append(*lines, sc.Text()) // 修改调用方的 slice 头
}
return sc.Err()
}
// 调用方
var results []string
parseLines(file, &results) // 必须取地址
func f(p *int) 和 func f(s []int) 的底层内存行为差异
两者都涉及指针，但层级不同：*int 是直接指向单个整数的指针；[]int 是值类型，其内部字段 ptr 才是指向底层数组首地址的指针。传 []int 时，复制的是整个 header（通常 24 字节），而传 *int 只复制 8 字节（64 位系统）。
- 传
*int：函数内*p = 42会改原始变量；传int则不会 - 传
[]int：函数内s[0] = 42会改底层数组；但s = append(s, 1)不会影响调用方的s - 没有「切片指针更省内存」这种说法——header 复制成本固定且极小；过度使用
*[]T反而增加间接访问和 nil 检查负担
性能优化的关键判断点：别过早优化 header 复制，盯紧底层数组分配
切片传参的性能瓶颈从来不在 header 复制，而在 append 触发的底层数组 realloc，或意外的全量拷贝（如 copy(dst, src) 未预估容量）。真正的优化应聚焦于此。
立即学习“go语言免费学习笔记（深入）”；
- 已知最大长度？用
make([]T, 0, max)预分配，避免多次扩容 - 函数返回新切片？优先返回
[]T，而非接收*[]T参数——语义更清晰，编译器也更容易做逃逸分析 - 怀疑逃逸？用
go build -gcflags="-m"查看变量是否被分配到堆；[]T参数本身几乎不逃逸，但其底层数组可能因生命周期延长而逃逸
最常被忽略的是：把本该一次性生成的切片，拆成多次小 append 并反复传指针，反而干扰了编译器对内存布局的判断。
