传指针不一定比传值快，小结构体（≤8字节）传值更快；大对象传指针可避免复制但需防逃逸；接口传值会复制整个结构，传指针才零拷贝；指针真正价值在于复用与控制内存生命周期。
为什么传指针不一定比传值快
Go 中传指针常被默认等同于“性能优化”，但实际是否提速，取决于结构体大小和使用方式。小结构体（比如 struct{a, b int}）按值传递可能比传指针更快——因为避免了内存间接寻址、缓存未命中，且小对象能直接压栈，CPU 流水线更友好。
实操建议：
- 结构体字段总大小 ≤ 机器字长（通常 8 字节）时，优先按值传递；
time.Time（24 字节）、sync.Mutex（24 字节）这类明显大于 8 字节的，才值得传指针 - 用
go tool compile -S查看汇编，确认是否真生成了MOVQ地址加载指令；若函数内联后直接操作字段，传值反而无额外开销 - 避免为“看起来高效”而盲目加
*：比如对type ID string加指针，不仅没收益，还增加 GC 压力
指针传递引发的逃逸分析失败
当局部变量取地址并返回（如 return &x），或传给全局 map/channel/函数参数（且该参数类型含指针），Go 编译器会将其分配到堆上，触发逃逸。这会增加 GC 负担，抵消“少复制”的收益。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 函数返回
*bytes.Buffer或*strings.Builder，导致内部字节数组逃逸 - 把局部结构体地址存进
sync.Pool，本意复用，却让原本可栈分配的对象全上堆 - 用
fmt.Sprintf("%v", &s)这类反射式调用，强制取地址并逃逸
验证方式：加 -gcflags="-m -l" 编译，观察输出中是否含 ... escapes to heap。
接口值里藏指针时的隐式拷贝成本
Go 接口是两字宽结构：type iface struct { tab *itab; data unsafe.Pointer }。当传 *T 给接口（如 io.Writer），data 字段存的是指针地址；但若传 T 值，则整个值被复制进 data 区域。问题在于：你以为传的是指针，实际可能被包装成值。
典型场景：
-
var w io.Writer = &bytes.Buffer{}→ 零拷贝，安全 -
var w io.Writer = bytes.Buffer{}→ 整个Buffer（含buf []byte底层数组头）被复制，后续w.Write()可能修改副本，原对象不受影响 - 函数参数为
func f(w io.Writer)，调用f(buf)（buf是值）→ 复制发生在此处，不是在函数体内
关键点：接口承载的是“值语义”，指针是否生效，取决于你传进去的是 &T 还是 T，而不是接口本身能不能存指针。
真正提升性能的指针用法：避免重复分配与共享状态
指针的核心价值不在“少传几个字节”，而在控制内存生命周期和共享可变状态。比如：
- 重用大对象：用
sync.Pool管理*bytes.Buffer，避免每次new(bytes.Buffer)触发堆分配 - 延迟初始化：字段声明为
*big.Int，只在首次Use()时if p == nil { p = new(big.Int) }，节省多数请求的内存 - 避免切片底层数组重复拷贝：传
[]byte本质是传结构体（{ptr, len, cap}），但若函数内需扩容，append可能分配新底层数组；此时传*[]byte并原地修改，可复用原有空间（需谨慎，破坏不可变性）
最易被忽略的一点：指针带来的性能收益，几乎总是绑定在「对象复用」或「避免 GC 扫描」上，而不是单纯减少一次 8 字节复制。没想清楚生命周期就加星号，大概率白忙活。
