Golang中Fire and forget模式goroutine是否存在泄漏风险？

• 这种Fire and forget用法只要后台任务不会永久阻塞/死循环，就不存在goroutine泄漏风险
• goroutine执行完所有任务代码后会被Go runtime自动终止，相关资源也会被正常清理，不需要手动做额外处理

Go的goroutine是runtime调度的用户态轻量级线程，当goroutine的入口函数（你代码里的匿名函数）执行完成后，runtime会自动将它标记为待销毁状态，它的初始栈内存、调度器关联的元数据都会被回收，运行过程中在堆上申请的内存也会由GC正常扫描回收，不会有资源残留问题。

虽然你当前的假设场景下不会出问题，但实际生产环境使用这种模式需要注意几个风险点：

• 不要直接在后台goroutine中使用handler传入的*http.Request自带的Context：handler返回时该Context会被立即取消，如果后台任务用这个Context做DB操作、接口调用等，会直接被中断返回错误。如果需要用到Context，建议用context.WithoutCancel(r.Context())或者新建一个带超时的根Context传入后台任务。
• 要做好panic防护：子goroutine的panic无法被父goroutine捕获，一旦后台任务出现panic，会直接导致整个进程崩溃，即使你认为逻辑不会出错，也建议在goroutine入口加defer recover()做兜底。
• 高QPS场景下做好限流：goroutine虽然轻量（初始栈只有2KB），但如果接口QPS很高，短时间内启动大量后台goroutine还是会占用过多内存，增加runtime调度开销，极端情况会导致服务OOM。这种场景建议用固定大小的worker池+任务队列来限制并发的后台任务数量。

import (
    "context"
    "log"
    "net/http"
    "time"
)

type TaskParam struct {
    // 定义后台任务需要的参数
}

func parseTaskParam(r *http.Request) TaskParam {
    // 从请求中提取后台任务需要的所有参数
    return TaskParam{}
}

func runLongTask(ctx context.Context, param TaskParam) {
    // 执行耗时5秒的业务逻辑
}

func DefaultHandler(w http.ResponseWriter, r *http.Request) {
    // 执行前置DB调用、业务逻辑
    taskParam := parseTaskParam(r)

    // 启动后台goroutine
    go func(param TaskParam) {
        // 兜底捕获panic，避免进程崩溃
        defer func() {
            if rec := recover(); rec != nil {
                log.Printf("background task panicked: %v", rec)
            }
        }()

        // 新建带超时的Context，避免后台任务无限阻塞
        ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
        defer cancel()

        runLongTask(ctx, param)
    }(taskParam)

    w.WriteHeader(http.StatusOK)
}

内容的提问来源于stack exchange，提问作者aks