Go中无法禁止GC回收对象，只能通过维持强引用来延长其生命周期；全局变量、活跃goroutine持有的变量、未清理的全局map等可使对象持续存活，但需警惕内存泄漏；runtime.KeepAlive仅防止编译器误优化，不干预GC标记。
Go 中对象生命周期由 GC 自动管理，无法“禁止回收”
Go 没有提供手动禁止 GC 回收某个对象的机制。所谓“让对象不被回收”，本质是**维持对该对象的强引用**，只要至少一个 goroutine 能通过变量、全局 map、channel、闭包捕获等路径访问到该对象，GC 就不会回收它。强行“锁住”内存不仅违背 Go 设计哲学，还会导致内存泄漏。
哪些方式会让对象持续存活（但需谨慎）
常见误以为“能阻止回收”的做法，实际只是延长了引用链。关键看引用是否可达：
-
var globalObj *MyStruct：全局变量持有指针 → 对象存活直到程序退出（或显式置nil） -
sync.Pool中暂存对象 → 不保证存活，Get()可能返回nil或旧对象，Put()后可能被后续runtime.GC()清理 - goroutine 持有局部变量并长期阻塞（如
select{}）→ 只要 goroutine 存活且变量在栈/堆上可达，对象不回收 - 注册到全局 map 并忘记清理：
objMap[id] = obj→ 对象永不回收，典型内存泄漏
为什么 runtime.KeepAlive() 不是“防回收开关”
runtime.KeepAlive() 仅影响**编译器对变量的逃逸分析和死代码消除**，不干预 GC 标记过程。它只在以下场景必要：
- 对象已传递给 C 函数（如
C.free(ptr)），但 Go 侧仍需确保该对象在 C 使用期间不被提前回收 - 对象被写入 unsafe 内存后，编译器可能误判其“已无用”而提前释放底层内存
例如：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
ptr := &MyStruct{}
C.use_in_c(ptr)
runtime.KeepAlive(ptr) // 确保 ptr 所指对象在 C.use_in_c 返回前不被 GC 回收
若没调用 C 函数，加 runtime.KeepAlive(x) 完全无效。
真正要警惕的是“以为对象还活着”的错觉
常见陷阱包括：
- 切片底层数组被其他变量引用 → 修改
s1可能意外影响s2，但两者都“存活”，并非 GC 问题，而是共享内存 - 闭包捕获局部变量后，该变量逃逸到堆 → 即使原函数返回，对象仍存活，但开发者常误以为“函数结束就销毁”
- 使用
unsafe.Pointer绕过类型系统 → GC 无法识别引用关系，极易造成悬挂指针或静默内存损坏
GC 的不可见性会让问题延迟暴露，比如对象在某次 GC 后突然变为 nil 或内容被覆盖——这时候不是 GC “错了”，而是你的引用逻辑本身存在漏洞。
