Go函数可安全返回局部变量指针，因编译器通过逃逸分析将需长期存在的变量自动分配到堆；但高频逃逸会增加GC压力，且跨goroutine共享指针易致竞态或内存泄漏。
Go函数能安全返回局部变量指针，因为编译器自动逃逸到堆
是的，func() *int 这类函数可以放心返回局部变量地址，Go 不会像 C 那样产生悬空指针。根本原因在于编译器在编译期做逃逸分析（Escape Analysis），一旦发现变量地址被返回、赋给全局变量、存入 map 或 slice、或传入 interface{}，就会把该变量从栈分配改为堆分配。
实操建议：
- 用
go build -gcflags="-m -l"查看逃逸详情，关键提示是“moved to heap: x”或“escapes to heap” - 不要手动模拟“栈上取地址再返回”的思维——Go 不需要你操心分配位置，但你要意识到：每次调用都可能触发一次堆分配
- 逃逸不是 bug，是安全机制；但高频逃逸（如循环中构造并返回指针）会抬高 GC 压力
返回指针 ≠ 控制生命周期，GC 只看是否可达
Go 指针本身不管理生命周期，它只是引用路径的一环。只要存在任意一条从根对象（如全局变量、goroutine 栈、正在运行的 channel）出发、能抵达该对象的指针链，GC 就不会回收它。
常见陷阱：
立即学习“go语言免费学习笔记（深入）”；
- 把临时构造的
*User存进包级var cache = make(map[string]*User)却忘了清理 → 对象永远无法回收 - 将
&largeStruct传给fmt.Errorf("err: %v", ...)→ 整个结构体因接口隐式持有而滞留内存 - 在长生命周期结构体字段中保存短命对象指针（如 HTTP handler 持有 request-scoped 数据的指针）→ 内存泄漏
诊断方法：pprof heap 看类型分配量，配合 runtime.SetFinalizer 打钩子验证对象是否如期释放（仅用于诊断）。
并发场景下指针共享极易引发竞态或延迟回收
多个 goroutine 通过同一指针读写同一块内存，既可能造成数据竞争（race），也可能让 GC 误判对象仍被活跃使用——哪怕逻辑上那个 goroutine 已经结束。
安全做法：
- 避免裸指针跨 goroutine 传递；优先用
channel发送值（或小结构体）转移所有权 - 若必须共享，用
sync.Mutex或sync.RWMutex显式保护临界区 - 运行时加
-race编译参数，主动暴露读写冲突（如go run -race main.go） - 特别注意：传入
interface{}的指针会被隐式延长生命周期，尤其在日志、错误包装、中间件等泛化场景中
与 C 交互时的指针生命周期完全由你负责
Go 调 C 产生的 *C.xxx 类型指针不受 GC 管理，它的生死完全取决于你是否调用对应 C.free 或 C 层释放逻辑。
必须遵守：
- 禁止把
*C.char直接塞进 Go 的map、slice或chan中长期持有 - 若需在 Go 侧持久化 C 数据，先用
C.GoBytes或unsafe.Slice复制到 Go 堆内存，交由 GC 管理 - 调用完 C 函数后，显式置 C 指针为
nil，并确保不再解引用
最易被忽略的是：你以为函数返回了，C 内存就安全了——其实只要 Go 侧还存着那个 *C.xxx，它就是悬空的，且无任何运行时检查。
