根本原因在于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) 未预估容量）。真正的优化应聚焦于此。

• 已知最大长度？用 make([]T, 0, max) 预分配，避免多次扩容
• 函数返回新切片？优先返回 []T，而非接收 *[]T 参数——语义更清晰，编译器也更容易做逃逸分析
• 怀疑逃逸？用 go build -gcflags="-m" 查看变量是否被分配到堆；[]T 参数本身几乎不逃逸，但其底层数组可能因生命周期延长而逃逸

最常被忽略的是：把本该一次性生成的切片，拆成多次小 append 并反复传指针，反而干扰了编译器对内存布局的判断。