该用指针传参当结构体大于16字节、需修改原值、含引用类型字段或方法需指针接收者；小结构体（如time.Time）值传参更优；slice/map本身是引用描述符，通常无需指针；逃逸分析比指针/值选择更关键。
什么时候该用指针，而不是值类型传参
Go 函数参数默认是值拷贝，对大结构体或切片底层数组来说，拷贝开销明显。但不是所有情况都该加 *——小结构体（比如 struct{a, b int}）按值传递反而更快，因为避免了额外的内存寻址和可能的逃逸分析开销。
判断依据主要看两点：结构体大小是否超过机器字长（通常 8 字节），以及是否需要在函数内修改原值。
- 小于等于 16 字节的结构体，多数场景下值传递更优（如
time.Time、sync.Mutex自身就是值类型，绝不能传指针） - 含 slice、map、chan、func 或 interface{} 字段的结构体，即使很小也建议传指针——这些字段本身是引用类型，但结构体整体拷贝仍会复制头信息（如 slice 的 len/cap/ptr），且容易触发不必要的堆分配
- 需要修改接收者状态的方法，必须用指针接收者（否则改的是副本）
slice 和 map 作为参数时，指针不是性能瓶颈，但容易误用
slice 和 map 本身已是引用语义的描述符（底层含指针），传值不会拷贝底层数组或哈希表，只拷贝 descriptor（24 字节或 32 字节）。所以 func f(s []int) 和 func f(s *[]int) 性能差异极小，但后者往往暴露设计问题。
常见误用：
立即学习“go语言免费学习笔记（深入）”；
- 把
*[]int当作“可扩容 slice”手段：实际扩容后原变量仍指向旧底层数组，除非显式赋值回原变量，否则调用方无感知 - 用
*map[string]int防止 nil panic：不如直接检查if m == nil，且 map 本身可安全写入 nil（会 panic），但指针解引用多一层风险 - 为统一接口而强行传指针：比如所有参数都用
*T，反而让调用方必须取地址，增加 GC 压力和逃逸概率
逃逸分析是比“指针 vs 值”更关键的性能开关
Go 编译器会根据变量是否被返回、是否被闭包捕获、是否被指针间接引用等，决定是否将其分配到堆上。一旦变量逃逸，无论你传值还是传指针，都会产生堆分配开销。
验证方式：用 go build -gcflags="-m -l" 查看逃逸报告。例如：
type Config struct {
Host string
Port int
}
func NewConfig() Config { return Config{"localhost", 8080} } // 不逃逸
func NewConfigPtr() *Config { return &Config{"localhost", 8080} } // 逃逸：&Config 必须堆分配
关键点：
- 返回局部变量的指针 → 必然逃逸
- 将局部变量地址传给未知函数（如
fmt.Printf("%p", &x)）→ 很可能逃逸 - 值类型在栈上分配快、回收零成本；堆分配涉及 GC 周期和内存碎片，影响远大于一次拷贝
interface{} 接收值或指针，行为完全不同
把值传给 interface{} 会拷贝原始数据，把指针传入则只拷贝指针本身。但更重要的是：接口的动态类型决定了方法集是否包含指针方法。
例如：
type User struct{ Name string }
func (u User) GetName() string { return u.Name }
func (u *User) SetName(n string) { u.Name = n }
var u User
var i interface{} = u // i 的动态类型是 User，只有 GetName()
var j interface{} = &u // j 的动态类型是 *User，有 GetName() 和 SetName()
这直接影响能否调用方法，也影响反射性能（reflect.ValueOf(u) 比 reflect.ValueOf(&u) 多一次拷贝）。若仅需读取字段或调用值方法，优先传值；若需修改或调用指针方法，才传指针。
真正影响性能的，往往不是拷贝本身，而是因错误使用指针导致本可栈分配的变量被迫逃逸，或者因接口类型不匹配引发隐式转换和额外反射开销。
