go 函数传参时，切片（24 字节）虽比裸指针（8 字节）稍大，但因远小于 cpu 缓存行（通常 128 字节），拷贝开销可忽略；更重要的是，切片天然封装了底层数组、长度与容量，语义清晰、安全且符合 go 的惯用法。
go 函数传参时，切片（24 字节）虽比裸指针（8 字节）稍大，但因远小于 cpu 缓存行（通常 128 字节），拷贝开销可忽略；更重要的是，切片天然封装了底层数组、长度与容量，语义清晰、安全且符合 go 的惯用法。
在 Go 中，理解“如何高效传递集合数据”是编写高性能、可维护代码的关键。初学者常误以为“指针一定更轻量”，从而倾向手动传递 *[]T 或 *[N]T，但这既不必要，也不推荐。
切片的底层结构决定其高效性
Go 中的切片是一个值类型，其运行时表示为一个三字段结构体（共 24 字节，64 位系统下）：
type slice struct {
array unsafe.Pointer // 指向底层数组首地址（8 字节）
len int // 当前长度（8 字节）
cap int // 容量（8 字节）
}传递切片时，仅复制这 24 字节——不复制底层数组本身，也不触发内存分配。相比之下，若传递数组值（如 [1000]int），则会完整复制全部元素；而传递 *[]T（指向切片头的指针）不仅增加间接寻址层级，还破坏了切片的自描述性，且无法反映长度/容量变更意图。
为什么不用 *[]T 或 *[N]T？
- *[]T 是对切片头的指针：多一层解引用，丧失切片的灵活性（如 append 后需显式更新原指针）；
- *[N]T 是固定长度数组指针：失去动态长度语义，无法适配不同大小输入，且调用方必须精确匹配 N；
- 更重要的是：Go 的标准库、内置函数（如 sort.Slice, strings.Split）和绝大多数生态代码均以 []T 为约定接口——使用切片即遵循语言共识。
实际对比示例
func processSlice(s []int) { s[0] = 99 } // 修改影响原底层数组
func processPtr(p *[]int) { (*p)[0] = 99 } // 冗余、易错、不可读
data := []int{1, 2, 3}
processSlice(data) // ✅ 自然、安全、高效
processPtr(&data) // ❌ 不必要，且若函数内执行 data = append(data, 4)，调用方不会感知性能与可维护性兼顾
现代 CPU 对小结构体（≤128 字节）的拷贝高度优化：24 字节与 8 字节在 L1 缓存内拷贝耗时几乎无差别；真正的性能瓶颈往往在于内存访问模式、缓存局部性或算法复杂度，而非参数大小。与此同时，切片提供的边界检查、len/cap 可见性、与 append/copy 等内置操作的无缝集成，显著提升了代码安全性与可读性。
✅ 结论：优先使用 []T 作为函数参数类型。它不是“妥协之选”，而是 Go 经过权衡后设计的最优抽象——兼具零拷贝语义、丰富元信息和强大生态支持。除非有极特殊场景（如与 C 互操作或极致内存受限嵌入式环境），否则无需绕过切片直接操作指针。
