Go语言panic怎么避免内存泄漏-Golang-PHP中文网

panic不会执行defer，导致资源泄漏；recover后闭包引用大对象会阻碍gc；panic不终止goroutine，子goroutine和ticker易失控。

go语言panic怎么避免内存泄漏

panic前未释放资源会直接导致泄漏

panic 不会自动触发 defer 的执行（除非用 recover 捕获），所以 defer f.Close()、defer conn.Close() 这类清理逻辑在 panic 发生时根本不会跑。常见后果是：文件描述符堆积、HTTP 连接池耗尽、数据库连接卡死——这些都不是 GC 能管的，内存和系统资源会持续上涨。

必须确保关键资源在 panic 可能路径上仍有释放机会：

所有打开资源的操作后，立刻跟 if err != nil { /* 清理 + return 或 panic */ }，并在清理分支里显式关闭
避免把多个资源初始化写在同一行，否则 panic 发生在中间位置时，前面已分配的资源就悬空了
对可能 panic 的工厂函数（如 NewDB、OpenFile），内部要做防御性清理：分配失败时反向释放已成功分配的部分

recover 后未处理闭包引用会拖住内存

用 recover() 捕获 panic 后，如果闭包里捕获了大对象（比如整个 *http.Request、长 slice、map），而这个闭包又被注册到全局日志、监控或重试队列中，那这些对象就逃逸出作用域却无法被 GC 回收。

典型错误模式：

func handleRequest(w http.ResponseWriter, r *http.Request) {
    defer func() {
        if p := recover(); p != nil {
            log.Printf("panic: %v, req: %+v", p, r) // ← 错！r 是指针，且可能带 body、context、headers 等重型字段
        }
    }()
    // ...
}

正确做法是只提取必要字段，不传指针：

记录 r.URL.Path、r.Method、r.RemoteAddr 这类小值，而非整个 r
若需上下文信息，提前用 ctx.Value() 提取并拷贝，别让闭包隐式持有 r.Context()
recover 后立即返回，不要在 defer 闭包里做异步操作（如 go sendToLog(...)）

panic 触发的 goroutine 泄漏更难发现

panic 本身不杀 goroutine；如果一个 goroutine 在 panic 前已启动子 goroutine 或启动了 time.Ticker，而主流程又没做清理，这些子任务就彻底失控。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

例如：

go func() {
    ticker := time.NewTicker(1 * time.Second)
    defer ticker.Stop() // ← panic 时这行不执行
    for {
        select {
        case <p>这种写法在 panic 场景下，<code>ticker</code> 永远不会 stop，goroutine 持续运行，内存和 goroutine 数量只增不减。解决方案很直接：</p>