Go中nil指针无需释放，GC自动管理内存；真正需显式释放的是文件描述符、网络连接等非内存资源，必须调用Close()等方法，而非仅赋nil。
Go 里 nil 指针本身不需要“释放”
Go 没有手动内存管理，nil 是一个零值，不是资源句柄。你给一个指针赋 nil，只是让它不再指向原来的结构体或对象，真正决定资源是否可回收的是该对象是否还有其他引用——这是 GC 的事，不是你的事。
容易踩的坑是误以为 p = nil 能“立刻释放内存”或“防止泄漏”，其实它只影响变量本身的引用计数；如果那个对象还被 channel、map、全局切片或闭包捕获着，GC 就不会动它。
- 对局部变量：赋
nil几乎无意义，函数返回后变量自动失效 - 对全局/长生命周期变量（如
var cache *BigStruct）：设为nil可帮助 GC 提前识别不可达对象，但前提是确认没有其他引用 - 对切片/映射/通道等引用类型字段：仅置空指针不够，还要考虑它们内部持有的资源（比如
os.File）
需要手动清理的其实是非内存资源
真正要“安全置空”的，从来不是指针本身，而是它背后封装的系统资源：文件描述符、网络连接、锁、CGO 分配的内存、定时器等。这些不归 GC 管，必须显式关闭或释放。
典型场景是自定义结构体持有 *os.File 或 net.Conn，此时 nil 指针只是表象，关键在 Close() 是否被调用。
立即学习“go语言免费学习笔记（深入）”；
- 别依赖
defer在 long-running goroutine 中保底关闭——万一 panic 没触发 defer，或者 defer 被提前跳过，资源就漏了 - 不要把
Close()和nil赋值混为一谈：f.Close(); f = nil是两件事，后者不能替代前者 - 若结构体实现了
io.Closer，优先用统一接口做清理，而不是裸写nil
示例：
type ResourceManager struct {
file *os.File
mu sync.RWMutex
}
func (r *ResourceManager) Close() error {
r.mu.Lock()
defer r.mu.Unlock()
if r.file != nil {
err := r.file.Close()
r.file = nil // 这步是防御性操作，防止重复 close
return err
}
return nil
}
unsafe.Pointer 和 CGO 场景下才真要“手动释放”
只有当你用 C.malloc、C.CString 或 unsafe.Pointer 绕过 Go 内存模型时，才存在真正的手动释放需求。这时 nil 不解决任何问题，必须配对调用 C.free 或对应 C 端释放函数。
常见错误是只把 Go 侧指针设为 nil，却忘了调用 C.free，导致 C 堆内存泄漏；或者重复调用 C.free 引发崩溃。
- 永远用
defer C.free(ptr)配合C.malloc，且确保ptr是原始分配返回值 - 避免把
unsafe.Pointer存进 map 或全局变量——GC 不会追踪它，也无法判断其指向是否有效 - 使用
runtime.SetFinalizer是高危操作，仅用于兜底，不能替代显式释放逻辑
结构体字段置 nil 的实际价值很有限
给结构体某个字段赋 nil，唯一可靠的作用是避免后续误用（比如防止对已关闭的 *http.Client 发起请求），或者辅助 GC 在特定路径下提早判定对象不可达。但它不是资源管理机制。
更值得关注的是字段是否实现了 io.Closer、sync.Locker 或其他可释放接口，以及你是否在所有退出路径（包括 panic）中都覆盖了清理逻辑。
- 不要在方法里只写
s.field = nil就认为“已清理”——先看这个字段有没有Close()方法 - 如果字段是接口类型（如
io.ReadCloser），直接调Close()更安全，不必先判空再赋nil - 测试时故意让相关字段为
nil并调用方法，观察是否 panic，能暴露很多隐性假设
复杂点在于：资源生命周期往往跨 goroutine，而 nil 是线程不安全的。多个 goroutine 同时读写同一指针字段，不加锁就设 nil，可能引发竞态或 use-after-free 类行为——这比内存泄漏更难排查。
