Gin与Mysql driver引发的服务崩溃
Gin与Mysql driver引发的服务崩溃
在 Go Web 服务中，*gin.Context 很容易被当作普通的请求参数向业务层传递。当业务层又启动异步任务，并在任务中继续使用这个对象时，请求生命周期和 goroutine 生命周期就会发生错位。高并发场景下，Gin 对象池的复用会把这个问题放大，最终触发 MySQL driver 的异常取消路径，导致进程 panic。
背景
一个 HTTP 请求进入 Gin 后，会获得一个 *gin.Context。这个对象保存了请求、响应写入器、路径参数、请求级变量和中间件状态。Gin 为了减少对象分配，会在请求结束后把 Context 放回 sync.Pool，下一次请求继续复用。
*gin.Context 因此具有明确的生命周期：它只属于当前 Handler 的同步执行过程。Handler 返回后，Context 的所有权就回到了 Gin，业务代码不能再持有它，也不能在后台 goroutine 中继续调用它的方法。
数据库查询应当接收标准库的 context.Context，例如：
rows, err := db.QueryContext(ctx, query, args...)
标准 Context 要满足一个重要约束：Done() 返回的通道和 Err() 必须描述同一个取消状态。当 Done() 被关闭后，Err() 必须返回非空错误。数据库驱动会依赖这个约束实现查询取消和连接回收。
问题
为了还原这个并发故障，下面构造一个虚构的内容聚合接口：它并发读取账户摘要和推荐条目，分别由 loadAccountSummary 和 loadRecommendedItems 完成。
问题代码的核心结构可以抽象为以下伪代码：
func handleRequest(c *gin.Context) {
accountErrCh := make(chan error, 1)
itemErrCh := make(chan error, 1)
go func() {
accountErrCh <- loadAccountSummary(c)
}()
go func() {
itemErrCh <- loadRecommendedItems(c)
}()
// 账户摘要没有记录时，业务分支直接返回错误。
if err := <-accountErrCh; err != nil {
c.JSON(http.StatusInternalServerError, errResponse(err))
return
}
_ = <-itemErrCh
}
实际运行链路如下：
- Handler 把原始
*gin.Context传入业务函数。 - 业务函数并发启动两个 goroutine，两个 goroutine 都持有同一个 Context。
loadAccountSummary查询不到记录，返回sql.ErrNoRows，上层将其转换为 HTTP 500 并立即返回。- Handler 返回后，Gin 把 Context 放回
sync.Pool。 - 推荐条目 goroutine 尚未结束，仍然使用原始 Context 执行
QueryContext。 - 高并发下，同一个 Context 对象被下一次请求取出，内部
Request指针改成了新请求的*http.Request。 - MySQL 查询取消 watcher 之前已经从旧请求取得了旧的
Done通道。 - 旧请求结束后，旧
Done通道被关闭，watcher 被唤醒。 - watcher 再调用同一个 Gin Context 的
Err()。此时 Gin 已经通过新的Request指针读取新请求的Request.Context()，新请求仍未取消，因此返回nil。 - driver 将这个
nil作为取消错误保存到atomic.Value，触发sync/atomic: store of nil value into Value，进程退出。
这个故障不是普通的数据库查询错误。HTTP 500 是业务流程提前返回的结果，进程崩溃则发生在请求结束后的异步 goroutine 中。
原因
原始 Gin Context 越过了请求边界
Gin Context 不是请求上下文的永久容器。它由 Gin 管理，并且会被对象池复用。后台 goroutine 持有它时，代码同时持有了一个会被其他请求重新初始化的可变对象。
c.Copy() 会创建一个独立的 Gin Context 对象。原始 Context 被放回对象池并重新初始化时，不会改写副本中的 Request 字段。这个复制动作必须发生在启动 goroutine 之前，所有并发分支只能读取复制后的 Context。
goroutine 没有被主流程等待
账户摘要分支返回错误后，主流程直接结束 Handler，没有等待推荐条目 goroutine。Handler 返回时，Gin 会把 Context 放回对象池，后续请求可以复用这个对象。
并发执行不等于可以提前返回。只要 goroutine 使用了请求级资源，就必须在 Handler 返回前完成等待，或者在任务开始前切换到独立且明确的任务上下文。
Context 的 Done 与 Err 被拆成了两个请求
MySQL driver 使用独立 goroutine 监听查询 Context。故障版本中的 watcher 核心代码如下：
func (mc *mysqlConn) startWatcher() {
watcher := make(chan context.Context, 1)
mc.watcher = watcher
finished := make(chan struct{})
mc.finished = finished
go func() {
for {
var ctx context.Context
select {
case ctx = <-watcher:
case <-mc.closech:
return
}
select {
case <-ctx.Done():
mc.cancel(ctx.Err())
case <-finished:
case <-mc.closech:
return
}
}
}()
}
watcher 通道接收的是一个 context.Context 接口。业务代码把原始 *gin.Context 传入数据库层后，这个接口的动态值仍然指向同一个 Gin Context 对象，并不会生成不可变快照。
第二段 select 在进入等待时调用 ctx.Done()，因此注册的是旧请求的取消通道。旧请求结束后，该通道关闭，执行流进入 mc.cancel(ctx.Err())。ctx.Err() 是一次新的方法调用；此时 Gin Context 已经被复用，它会通过已经替换的 Request 指针读取新请求的状态。新请求尚未取消，返回值就是 nil。
正常的标准 Context 中，Done() 和 Err() 属于同一个取消状态。故障场景将两次方法调用拆到了两个请求上，破坏了 context.Context 的一致性约束：旧请求的通道表示取消已经发生，新请求的 Err() 却返回 nil。
atomic.Value panic 是二次故障
atomic.Value 第一次存储后会固定存储类型，同时禁止存储 nil。driver 的取消逻辑收到空错误后执行 Store(nil)，因此产生 panic。
修复 atomic.Value.Store(nil) 可以阻止这一次 panic，但不能修复 Context 被复用的问题。driver 只是最先暴露了这个生命周期错误的组件，根因仍然是业务代码在 Handler 返回后继续使用 *gin.Context。
解决
在启动 goroutine 前复制 Gin Context
Handler 进入业务层前，必须先调用 c.Copy()。业务函数和并发分支使用复制后的 Context，Handler 仍然使用原始 Context 写入响应：
func handleRequest(c *gin.Context) {
copied := c.Copy()
result, err := buildResponse(copied, requestID(c))
if err != nil {
c.JSON(http.StatusInternalServerError, errResponse(err))
return
}
c.JSON(http.StatusOK, result)
}
c.Copy() 必须在 Handler 的同步流程内执行，不能进入 goroutine 后再复制原始 Context。复制后的 Context 不会被 Gin 放回请求对象池，因此原始 Context 被下一次请求复用时，副本的 Request 字段仍然指向原请求。
副本只能用于读取请求信息，不能调用 JSON、Next、Abort，也不能通过 Writer 写入响应。参数、Header 和认证信息仍应优先提取为普通值，减少业务层对 Gin 类型的依赖。
使用 errgroup 等待并发任务
两个查询属于同一个请求，应该使用 errgroup.WithContext 管理取消和等待：
func buildResponse(c *gin.Context, accountID string) (*Response, error) {
ctx := c.Request.Context()
group, ctx := errgroup.WithContext(ctx)
var accountSummary AccountSummary
var items []Item
group.Go(func() error {
value, err := loadAccountSummary(ctx, accountID)
if errors.Is(err, sql.ErrNoRows) {
// 业务上允许不存在时，转换为明确的空结果。
accountSummary = AccountSummary{}
return nil
}
if err != nil {
return err
}
accountSummary = value
return nil
})
group.Go(func() error {
value, err := loadRecommendedItems(ctx, accountID)
if err != nil {
return err
}
items = value
return nil
})
// Wait 会等待所有 goroutine 退出，禁止后台任务越过 Handler 生命周期。
if err := group.Wait(); err != nil {
return nil, err
}
return &Response{
AccountSummary: accountSummary,
Items: items,
}, nil
}
errgroup 的错误语义需要与业务语义匹配。sql.ErrNoRows 如果代表“没有账户摘要”，就应转换为空结果或领域错误，不能未经判断直接变成 HTTP 500。真正的系统错误返回后，其他任务会收到取消信号，但 Wait 仍然会等待它们退出。
数据库调用必须使用稳定的 Context
复制 Gin Context 后，从副本中提取稳定的标准 Context，并沿调用链传给数据库层：
func loadRecommendedItems(ctx context.Context, accountID string) ([]Item, error) {
rows, err := db.QueryContext(ctx, `
SELECT id, title
FROM recommended_items
WHERE account_id = ?
`, accountID)
if err != nil {
return nil, err
}
defer rows.Close()
return scanItems(rows)
}
不能把原始 *gin.Context 直接传给 QueryContext，也不能在数据库层通过类型断言再读取 Gin 的 Request。c.Copy() 负责隔离 Gin 对象池复用，复制后的 Request.Context() 负责向数据库驱动提供稳定的取消状态，两者解决的是不同层次的问题。
需要后台执行时，创建独立任务
如果任务确实不需要等待请求结果，例如生成报表、异步对账或发送通知，就不应把 goroutine 直接挂在 Handler 里。正确做法是把任务写入消息队列或任务表，由独立 worker 消费，并为 worker 创建自己的超时 Context：
func enqueueReport(c *gin.Context, accountID string) error {
return taskQueue.Publish(Task{
AccountID: accountID,
RequestID: requestID(c),
})
}
func handleReportTask(task Task) error {
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
return generateReport(ctx, task.AccountID)
}
任务消息只携带必要的业务值，不携带 *gin.Context、*http.Request 或响应写入器。任务的重试、超时和幂等由 worker 负责。
c.Copy() 的使用约束
Gin 提供 c.Copy() 用于在 goroutine 中读取独立的 Context 副本，这是隔离本次对象池复用故障的关键步骤。副本中的 Request 仍然指向原请求，但副本本身不受原始 Gin Context 重新初始化的影响。
c.Copy() 不能替代 errgroup.Wait()。复制解决的是 Context 对象复用，等待解决的是 goroutine 生命周期失控。请求内并发查询应当同时使用两者：先复制 Context，再从副本提取标准 Context，最后等待全部任务退出。对于真正的后台任务，仍然应使用队列和独立任务 Context。
总结
这次崩溃的完整因果链是：业务分支提前返回，后台 goroutine 越过 Handler 生命周期继续使用原始 *gin.Context，Gin 复用 Context 后改变了 Request 指针，MySQL watcher 取得旧 Done 后又读取新 Err()，最终把 nil 写入 atomic.Value 并触发 panic。
修复的关键不是给 panic 加保护，而是恢复请求上下文的生命周期边界：Handler 在启动 goroutine 前调用 c.Copy()；业务层只读取复制后的 Gin Context；数据库层使用副本中的标准 Request.Context()；请求内并发任务必须等待；后台任务使用独立的任务上下文。这样才能同时解决 Context 复用、查询取消失配和进程崩溃三个问题。