context 本身不生成 sql 执行上下文，需显式传入带超时或取消能力的 context.context 实例；应避免使用 context.todo() 或裸 context.background()，推荐从 http 请求透传并增强，如 context.withtimeout(r.context(), time.second*3)。
context.Context 本身不能“生成 SQL 执行的 Context”——它只是 Go 标准库中用于传递取消、超时和值的接口。真正需要的是：在调用 db.QueryRowContext、db.ExecContext 等方法时，传入一个带超时或取消能力的 context.Context 实例。GoLand 不提供“一键生成 SQL Context”的专用功能，但可通过快捷键 + 模板快速构造常用上下文。
用 Ctrl+Shift+Space 补全 context.WithTimeout 等函数
在写 SQL 调用前（比如刚输入 db.QueryRowContext(），按下 Ctrl+Shift+Space（Windows/Linux）或 Cmd+Shift+Space（macOS），IDE 会根据当前包导入情况推荐最匹配的 context 构造函数：
- 若已导入
"context"，会优先列出context.WithTimeout、context.WithCancel、context.Background - 若光标在括号内且已有变量名（如
ctx），可能直接补全ctx而非构造函数 - 补全后按
Tab可跳转到参数占位处，快速填入time.Second * 5或time.Minute等
避免手写 context.TODO() 或 context.Background() 当作默认值
很多人图省事，在 SQL 调用里直接传 context.TODO() 或 context.Background()，但这会丢失超时控制能力，且 TODO() 是明确用于“待补充”的占位符，上线后容易被忽略：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
context.TODO()不应出现在生产代码中；它只用于开发早期、上下文尚未明确时的临时占位 -
context.Background()虽合法，但无超时，一旦 DB 连接卡死或慢查询，整个 goroutine 就挂住 - 正确做法是：对每个 SQL 调用，显式绑定合理超时，例如
context.WithTimeout(ctx, time.Second*3)
从 HTTP handler 透传 ctx 到 SQL 层最安全
如果你在 Gin / Echo / net/http handler 中执行 SQL，别在 handler 内部新建 context，而应从入参 *gin.Context 或 http.Request.Context() 向下透传并增强：
- Gin 中：用
c.Request.Context()获取原始请求上下文，再套一层WithTimeout - 不要写
ctx := context.WithTimeout(context.Background(), ...)—— 这会切断请求生命周期，导致无法响应客户端中断（如浏览器关闭连接） - 如果 handler 已有自定义中间件注入了值（如用户 ID），用
context.WithValue继续携带，而非丢弃
Alt+Enter 初始化 context 变量易踩空指针坑
当光标停在 var ctx context.Context 行按 Alt+Enter → “Initialize variable”，GoLand 会自动补成 ctx: nil：
- 后续直接传给
db.QueryRowContext(ctx, ...)会 panic：panic: context must not be nil - 必须手动改成
ctx := context.Background()或更合理的构造方式 - 更稳妥的做法是：不声明空变量，而是直接内联构造，例如
db.QueryRowContext(context.WithTimeout(r.Context(), time.Second*2), "SELECT ...")
真正关键的不是“怎么生成 Context”，而是“在哪构造、带什么约束、是否可取消”。GoLand 能帮你补函数、推导类型、检查 nil，但它不会替你决定超时该设 2 秒还是 30 秒——这个决策必须基于你的 SQL 复杂度、DB 响应水位和业务容忍度来定。
