❓背景
在使用 GORM + Gin 开发 Web 服务时，我们常常会把 gin.Context 的请求上下文 c.Request.Context() 传给数据库操作，以实现：

✅ 全链路 tracing（OpenTelemetry、SkyWalking、Jaeger 等）

✅ 请求取消时自动终止 SQL 执行，节省资源

但你是否遇到过 线上频繁出现 context canceled 报错，甚至数据写入丢失 的问题？

👇 错误日志示例：

shell

pq: context canceled

🧨 问题来源
当用户网络不佳、请求被取消（比如 App 后台、网络断开）时，gin.Context 关联的 ctx 会被自动关闭。

如果你的代码类似这样：

go

ctx := c.Request.Context()
db := db.WithContext(ctx)
err := db.Create(&model).Error

一旦请求中断，GORM 会感知到 ctx 被 cancel，主动中断 SQL 写操作！

✅ 适用于查询
⚠️ 不适用于重要写操作（如创建订单、积分更新、用户状态等）

✅ 解决方案：延长写操作生命周期
我们需要在写操作时：

脱离请求上下文生命周期，使用 context.Background()；

保留 tracing 信息，用于链路追踪；

设置合理的写入超时（如 3 秒），防止泄漏。

🛠 代码封装：GetWriteDBWithTrace()
你可以使用如下封装函数，统一处理 GORM 写操作的上下文问题：

go

package utils

import (
	"context"
	"time"

	"github.com/gin-gonic/gin"
	"go.opentelemetry.io/otel/trace"
	"gorm.io/gorm"
	"your_project_path/client" // 替换为你的项目 DB 包路径
	"go.uber.org/zap"
	"your_project_path/conf"
)


// GetWriteDBWithTrace 获取用于写操作的 db 和 context，保留 tracing，保障业务可靠性
func GetWriteDBWithTrace(c *gin.Context) (*gorm.DB, context.Context, error) {
	reqCtx := c.Request.Context()

	// 提取当前请求的 tracing span（OpenTelemetry）
	span := trace.SpanFromContext(reqCtx)

	// 派生一个背景 context，用于保障写入，即使请求已取消
	writeCtx := trace.ContextWithSpan(context.Background(), span)

	// 设置最长写入时间，防止 goroutine 泄漏
	writeCtx, cancel := context.WithTimeout(writeCtx, 3*time.Second)
	// ⚠️ 调用者需 defer cancel()

	db, err := client.GetDbClient()
	if err != nil {
		conf.Logger.Error("GetDbClient failed", zap.Error(err))
		cancel()
		return nil, nil, err
	}

	return db.WithContext(writeCtx), writeCtx, nil
}

🔁 使用方式
在你需要进行写入的地方这样用：

go

db, writeCtx, err := utils.GetWriteDBWithTrace(c)
if err != nil {
	return
}
defer cancel() // 别忘了！

// 后续写入操作
if err := db.Create(&yourModel).Error; err != nil {
	// handle error
}

📌 补充建议
场景 建议做法
读操作 可直接使用 c.Request.Context()，确保资源自动释放
写操作 使用 Background 派生 + Timeout 封装，避免误中断
大型项目 封装 GetReadDBWithTrace 与 GetWriteDBWithTrace 区分读写逻辑
支持 trace 使用 OpenTelemetry，trace context 可注入新 context 中

✅ 总结
在高并发场景下，context canceled 很常见，尤其在移动端 App 后台、网络抖动时。
写操作中直接使用 request.Context() 是危险的行为，会导致数据写入失败却不自知。

推荐最佳实践：

⚠️ 写操作：不依赖 request context，而是封装 Background + Timeout + Tracing

✅ 保持可观测性

✅ 提升写操作鲁棒性

希望这篇文章能帮你彻底解决这个线上“隐形 bug”！
有帮助欢迎点赞 + 收藏，有问题欢迎评论区一起交流～

如需获取完整示例代码，可私信我或评论区留言！

📌 关注我，一起写出稳健的 Golang 服务 ✨