传指针不一定节省内存，因对象分配位置（栈或堆）才是关键：栈上小结构体传值更高效，堆上大对象应复用而非仅传指针，interface{}隐式取地址还会强制堆分配。
为什么传指针不一定节省内存
Go 中函数传参永远是值传递，传结构体时会复制整个对象。但传 *struct 本身只复制一个指针（通常 8 字节），看起来省内存——可如果被指向的结构体在堆上新分配，反而增加 GC 压力和内存碎片。关键不在“传什么”，而在“对象在哪分配”。new()、&T{}、逃逸分析判定为堆分配的变量，都会让对象落在堆上。
实操建议：
- 用
go build -gcflags="-m -m"查看变量逃逸情况，确认结构体是否真逃逸到堆 - 小结构体（如
type Point struct{ X, Y int }）直接传值更高效，CPU 缓存友好，避免间接寻址开销 - 避免无意义取地址：比如
foo(&bar)中bar是局部变量且未被闭包捕获，却强制堆分配
切片和 map 的底层指针本质已帮你省内存
[]byte、[]int、map[string]int 这些类型本身是 header 结构（含指针字段），传参或赋值时只拷贝 header（24 或 32 字节），不复制底层数组或哈希表数据。你不需要、也不应该手动传 *[]T 或 *map[K]V 来“优化”。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 写
func process(data *[]string) { ... }，以为能省内存，实际多了一层指针解引用，还可能掩盖真实意图 - 对 map 做
m := &originalMap再传，完全多余；map 已是引用语义类型 - 用
make([]byte, 0, 1024)预分配容量，比反复 append 后扩容更省内存，这比纠结指针更有实效
用 sync.Pool 复用指针对象，而非频繁 new
高频创建/销毁大结构体（如 HTTP 请求上下文、解析器状态）时，堆分配 + GC 是主要内存瓶颈。此时应把对象放入 sync.Pool，复用其内存，而不是靠传指针“省一点”。指针只是入口，真正省的是分配次数。
使用场景与要点：
- 适合生命周期明确、可重置的对象：例如
type Parser struct { buf []byte; pos int }，每次用完调p.Reset()清空状态 - Pool 中对象可能被 GC 回收，不能依赖其存在；务必检查取出后是否为 nil 并 fallback 初始化
- 不要把含 finalizer 或需精确控制生命周期的对象放 Pool；它不保证对象存活时间
interface{} 传指针引发的隐式堆分配
当把一个栈上变量的地址转成 interface{}（如 any(&x)），Go 编译器会将该变量提升到堆——因为 interface{} 可能逃逸出当前作用域，必须确保其地址长期有效。这容易被忽略，却是真实内存上涨源头。
典型例子：
func logValue(v interface{}) { /* ... */ }
var id int = 42
logValue(&id) // id 被强制堆分配！
规避方式：
- 若函数逻辑允许，改用泛型：
func logValue[T any](v *T)，不触发 interface{} 逃逸 - 对简单类型（int、string、bool），直接传值；只有真正需要修改原值时才传指针
- 用 go tool compile -S 看汇编输出里是否有
call runtime.newobject，确认是否发生意外堆分配
真正影响 Go 内存占用的，从来不是“该不该传指针”，而是变量逃逸路径、对象复用策略、以及是否误触 interface{} 的隐式堆分配机制。盯着指针本身优化，往往治标不治本。
