Go中应优先对大结构体（>8字节）、需修改字段的场景用指针传参，避免复制开销；但基础类型、小结构体、接口值传指针反而增加间接寻址成本和逃逸压力。
什么时候该用指针传参而不是值传参
Go 默认按值传递，结构体或大对象拷贝开销明显。当函数只读或只修改字段时，传 *T 能避免复制，尤其对 > 8 字节的结构体（如含多个字段的 struct、切片头、map header 等）效果显著。
但别盲目加星号：基础类型（int、string）、小结构体（如两个 int 字段）、接口值本身已含指针语义，传指针反而增加间接寻址成本和逃逸分析压力。
- 典型适合场景：
func processUser(u *User)（User含 5+ 字段且函数内修改字段） - 反例：
func add(a, b *int)—— 基础类型传指针无意义，还强制变量逃逸 - 验证方式：用
go build -gcflags="-m" main.go查看变量是否逃逸；若提示... moved to heap，说明传指针导致了额外堆分配
如何避免指针导致的意外内存泄漏
指针延长了底层数据的生命周期。最常见的是从切片或 map 中取元素地址后，整个底层数组/哈希表无法被 GC 回收。
例如：ptr := &users[0] 后，即使 users 局部变量结束，只要 ptr 还活着，整个 users 底层数组就钉在堆上。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 安全做法：只对生命周期明确、作用域可控的变量取地址，比如局部 struct 的字段、新分配的对象
- 高危模式：从
[]byte、map[string]T或函数返回的切片中取地址并长期持有 - 替代方案：需要“引用”语义时，优先用索引（
idx int）或 key（key string）代替指针；必须用指针时，确保其生命周期 ≤ 它所指向数据的生命周期
sync.Pool + 指针复用能否真正减内存压力
可以，但前提是对象大小稳定、构造开销高、且使用频次足够。直接拿 *bytes.Buffer 或 *sync.Pool 自定义对象是常见做法，但要注意 Pool 不保证对象一定复用，也不清理内存。
关键限制在于：Pool 中的对象可能被任意 goroutine 拿走，若你存的是带指针字段的 struct（如含 *[]byte），而没重置这些字段，下次取出时会残留旧数据或引发 panic。
- 必须重置字段：
buf.Reset()、手动清空 slice 字段（obj.data = obj.data[:0]） - 禁止存含 finalizer 的对象，Pool 不调用 finalizer
- 不适用于有状态的对象（如带未关闭文件描述符的 struct），因为复用前无法保证状态干净
- 性能收益需实测：用
go tool pprof对比 allocs/op 和 heap_inuse，避免“以为省了，其实只是延迟了分配”
unsafe.Pointer 转换指针真的能省内存吗
不能直接省内存，但可绕过类型系统做零拷贝操作，间接减少临时分配。比如将 []byte 转为 *string 避免字符串构造开销，或将 reflect.Value 转为原始类型指针跳过反射调用。
代价极高：破坏 Go 的内存安全模型，一旦底层布局变化（如 struct 字段重排、编译器优化改写），程序可能静默读错数据或崩溃。
- 仅限极少数场景：高性能序列化库（如
msgpack）、底层网络包解析、与 C 交互桥接 - 永远不要在业务逻辑里用
unsafe.Pointer做“优化”，它不是优化手段，是最后的逃生通道 - 若必须用，务必用
go:build !race标记，并在 CI 中跑带-race的测试 —— race detector 对 unsafe 操作基本失效，但至少能捕获周边并发问题
指针不是银弹，真正的内存优化往往来自控制数据生命周期、减少不必要的中间对象、以及理解逃逸分析结果，而不是堆里多几个星号。
