必须用*[]T仅当函数需修改原切片的len/cap/ptr（如append后让调用方看到变化），常见于流式读取、封装多次append且不返回、避免循环中反复赋值；否则优先用[]T以保持清晰安全。
在 Go 中，切片本身已经是引用类型（底层包含指针、长度和容量），但传递切片参数时，仍会拷贝切片头（slice header）——即 24 字节（64 位系统）的结构体。这开销极小，通常无需优化。但如果你需要函数能修改原始切片的底层数组内容（比如批量赋值、解码数据），直接传 []T 就够了；而若函数需改变切片本身的长度或容量（例如 append 后想让调用方看到新长度），就必须传 *[]T（指向切片的指针）。
什么时候必须用 *[]T？
只有当函数内部执行了 append 或其他操作导致切片 header（尤其是 len/cap/ptr）发生变化，且你希望这些变化反映到调用方变量上时，才需要指针切片。常见场景包括：
- 从 io.Reader 逐步读取并动态扩容填充切片（如解析流式 JSON 数组）
- 函数封装了多次
append，且不返回新切片（比如为了复用或隐藏实现） - 避免在循环中反复返回并重新赋值切片（减少调用方代码冗余）
如何正确使用 *[]T 参数
声明函数时写 func f(s *[]byte)，调用时传地址：f(&data)。函数内通过 *s = append(*s, ...) 修改原切片。注意：如果 append 导致底层数组扩容，新数组地址会更新，*s 就能指向它。
示例：
立即学习“go语言免费学习笔记（深入）”；
func readAll(r io.Reader, buf *[]byte) error {for {
if len(*buf) == cap(*buf) {
newBuf := make([]byte, len(*buf), max(2*cap(*buf), 1024))
copy(newBuf, *buf)
*buf = newBuf
}
n, err := r.Read((*buf)[len(*buf):cap(*buf)])
*buf = (*buf)[:len(*buf)+n]
if err == io.EOF { break }
if err != nil { return err }
}
return nil
}
调用：var data []byte; readAll(r, &data) —— 函数结束后 data 已含全部读取内容。
多数情况：用 []T 更清晰、更安全
如果只是遍历、修改元素值（如 s[i] = x）、或用 append 但由调用方处理返回值，就该用 []T。这样语义明确、不易出错，且无额外解引用开销。Go 官方文档和标准库也普遍采用这种风格（如 bytes.TrimSuffix, strings.ReplaceAll）。
反例（不推荐）：
func badAppend(s *[]int, x int) { *s = append(*s, x) } // 调用方必须写 &s，易忘、难读正例（推荐）：
func goodAppend(s []int, x int) []int { return append(s, x) }调用：s = goodAppend(s, 42) —— 显式、可控、符合 Go 习惯。
性能提醒：别过早优化
切片头拷贝仅 24 字节，现代 CPU 几乎无感知。除非 pprof 明确显示 slice header 拷贝是瓶颈（几乎不会），否则优先选可读性。用 *[]T 主要解决“能否影响原切片结构”的逻辑问题，而非性能问题。
