指针变量本身的生命周期由作用域决定：它在栈上分配，随作用域结束自动释放，与其指向对象的生命周期无关；指向的内存生命周期则由GC可达性及逃逸分析共同决定。
指针变量本身的生命周期由作用域决定
声明一个指针变量，比如 var p *int，它本身只是一个 8 字节的地址值，和普通 int 变量一样，在栈上分配、随作用域结束而释放。它的生命周期不取决于它指向的对象——哪怕 p 指向堆上分配的内存，p 自身仍可能早已被回收。
常见误解是“指针一创建，它指向的东西就活了”。其实：指针变量只是个“路标”，路标撤掉，路还在；但没人读这个路标，那条路是否还被需要，得看别的引用是否还存在。
- 函数内定义的
ptr := &x，函数返回后ptr就失效（栈帧销毁），即使x是局部变量且被取了地址，该地址也变成悬垂（dangling） -
return &x能成功，是因为编译器做了逃逸分析，把x搬到堆上——不是因为&x让它活下来，而是因为“要被返回”这个行为触发了堆分配 - 用
go build -gcflags="-m -m"看输出里有没有moved to heap，比猜更可靠
指针指向的内存生命周期由 GC 决定，但受逃逸影响
Go 中没有手动 free，指针指向的内存何时回收，全看 GC 是否还能从根对象（全局变量、栈上变量、寄存器）追踪到它。但关键点在于：**能被追踪到，不等于一定在堆上；不能被追踪到，也不等于立刻回收**。
典型陷阱：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
func f() *string { s := "hello"; return &s }—— 表面看s是字符串字面量，但实际s是局部变量，&s会强制其逃逸到堆，返回合法；而return &"hello"直接报错：cannot take the address of "hello" -
var global *int; func init() { x := 42; global = &x }——x逃逸到堆，global持有有效引用，GC 不会回收；但如果global后续被设为nil且无其他引用，这块内存就可被回收 - 往
map[string]*T或[]*T存指针，只要该容器本身还活着，它持有的所有*T都不会被 GC 回收——哪怕原变量早超出作用域
nil 指针不是“空引用”，而是明确的未初始化状态
var p *int 声明后，p == nil 是确定的。它和 Java 的 null 或 Python 的 None 不同：Go 的 nil 是类型安全的零值，*int、*string、*http.Client 的 nil 互不兼容，不能混用。
解引用 nil 指针必 panic：panic: runtime error: invalid memory address or nil pointer dereference。这不是偶发错误，是设计使然——Go 强制你显式检查。
- 方法接收者为
*T时，调用nil值的方法不会立即 panic，除非方法体里访问了T的字段或调用了其方法（比如(*sync.Mutex).Lock()在nil上会 panic） - 接口变量包含
nil指针时，接口本身不为nil（因为接口有类型信息），容易误判：var w io.Writer = (*bytes.Buffer)(nil); if w == nil { ... }这个判断恒为 false - 传参时若函数文档没写“允许
nil”，就别传；传了也别指望它有默认行为——Go 不搞隐式兜底
指针接收者的方法不延长底层值的生命周期
定义 func (p *T) Foo() 并不意味着 T 实例会因该方法被调用而“活得更久”。方法执行期间，p 是个栈上变量，指向某个 T；方法结束，p 消失，T 的生命周期只取决于它原本的引用关系。
真正影响生命周期的是：你是否把 p 存到了包级变量、传给了 goroutine、塞进了 map 或 channel——这些操作才会让 GC 必须保留它。
-
func (p *User) Save() { db.Save(p) }—— 如果db.Save内部把p缓存起来，那User就不会被回收；如果db.Save只读字段并立即返回，则无影响 -
go func(u *User) { log.Println(u.Name) }(user)—— 这里user被捕获进闭包，只要 goroutine 没结束，user就不能被回收 - 用
c.Copy()复制 Gin 的*gin.Context时，它不复制c.Request和c.Writer，所以子 goroutine 里用c.Copy()得到的 Context 依然共享原始请求上下文——生命周期绑定在原请求上，不是复制出来的那个指针
