Go中传指针本身不省内存（64位下仅8字节），真正节省在于避免大结构体值拷贝；必须用指针时包括调用* T方法、修改原结构体字段、满足接口方法集要求；需警惕逃逸分析导致堆分配及指针带来的可读性、空值和GC负担问题。
Go里传指针不等于省内存
传指针本身几乎不节省内存——*T 在 64 位系统上就是 8 字节，和传一个 int64 大小一样。真正影响内存占用的是：你传的是值拷贝（比如大结构体）还是只传地址。如果 T 是 1KB 的 struct，每次传值就拷贝 1KB；传 *T 只拷贝 8 字节，这时才“省”。但这个“省”是避免冗余拷贝，不是指针本身更轻量。
什么时候必须用指针？看方法集和可变性需求
Go 的方法接收者决定了类型是否能调用某方法。如果方法定义在 *T 上，那只有 *T 实例能调用它；传 T 值进去，编译器不会自动取地址（除非是可寻址的变量）。常见踩坑：
- 对字面量或函数返回值直接调用
*T方法：会报cannot call pointer method on ... - 想在函数内修改原始 struct 字段，却传了值类型 → 修改无效
- 接口变量存储了
T，但方法集只包含*T→ 接口断言失败
示例：
type User struct{ Name string }
func (u *User) SetName(n string) { u.Name = n }
func main() {
u := User{} // u 是值
u.SetName("A") // ✅ ok：u 可寻址
User{}.SetName("B") // ❌ compile error
}
sync.Pool 和逃逸分析让指针行为更隐蔽
看起来用了指针，但实际分配可能仍发生在堆上——尤其当编译器判定变量“逃逸”时。比如局部 struct 指针被返回、传入 goroutine、或存入全局 map，Go 就会把它分配到堆，而不是栈。这时候“用指针”反而增加了 GC 压力。
验证方式：加 -gcflags="-m" 看逃逸分析输出，关注 ... escapes to heap。常见触发点：
立即学习“go语言免费学习笔记（深入）”；
- 返回局部变量的指针（如
&User{}） - 把指针存进
sync.Pool或全局切片 - 作为 channel 元素发送（channel 底层持有堆引用）
struct 字段用指针字段要小心零值语义
定义 type Config struct{ Timeout *time.Duration } 看似灵活，但带来两个实际问题：
- JSON 解析时，
null会变成nil指针，访问前必须判空，否则 panic - 字段默认零值是
nil，不是0，容易漏掉初始化逻辑 - 比较两个
Config是否相等需深比较，==直接失效
除非明确需要“三态”（未设置 / 设置为 nil / 设置为具体值），否则优先用值字段 + 零值有意义的设计（如 Timeout time.Duration，0 表示默认超时）。
指针真正的代价不在大小，而在可读性、生命周期管理和 GC 跟踪范围——这些比几字节内存重要得多。
