goland 不提供 context 逻辑支持，仅辅助语法；context 必须手动创建、传递、监听和取消，关键点包括 http 入口用 req.context()、db/grpc/http client 显式传 ctx、goroutine 启动时传 ctx 而非闭包捕获、withvalue 键需全局唯一变量且不传业务参数。
context 不是 GoLand 的功能，也不是 IDE 能“生成”的东西——它必须由你手动创建、传递、监听和取消。GoLand 只提供语法高亮、参数提示、跳转定义等辅助能力，**不会、也不能替你决定何时用 WithTimeout、该不该调用 cancel()、或在哪儿监听 Done()**。
真正卡住人的，从来不是“怎么敲代码”，而是“在哪儿加、加完之后要不要检查、漏了会怎样”。下面直说实操要点。
为什么 GoLand 的 context 提示看起来“没用”
GoLand 对 context 相关函数（如 WithTimeout、WithValue）有自动补全和类型推导，但它的提示只告诉你“这个函数签名长啥样”，不告诉你：
-
ctx必须作为第一个参数传入，且所有下游函数都得显式接收并透传——GoLand 不会帮你插到每个函数签名里 -
cancel()必须被调用，否则子上下文永远不释放；GoLand 不会警告你defer cancel()漏写了 -
Value()返回interface{}，类型断言失败时 panic；GoLand 的类型提示无法预防运行时 panic
哪些地方必须手动加 context，GoLand 不会提醒你
这些是高频遗漏点，也是线上 goroutine 泄漏的主因：
- HTTP handler 入口：必须从
http.Request.Context()拿，而不是直接用context.Background() - 数据库查询：
db.QueryContext(ctx, ...)和db.ExecContext(ctx, ...)—— 用错成Query()就彻底绕过 context 控制 - 第三方 client 调用：比如
http.Client.Do(req.WithContext(ctx))或 gRPC 的client.Method(ctx, req)，漏掉.WithContext(ctx)或传错ctx，超时就失效 - 启动 goroutine 时：必须把
ctx显式传进去，不能依赖闭包捕获外层变量（尤其当外层ctx是局部变量时）
Value() 传参时最容易翻车的三个细节
WithValue 看似简单，但一写错就难排查：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 键必须是全局唯一变量（如
type userIDKey int; const userIDKey = iota），不能用字符串字面量（"user_id"）——不同包里同名字符串会被视为不同键 - 值不能是可变结构体（如
map、slice），因为Value()返回的是副本引用，修改后上游不可见；若真要传 map，应传指针或封装为只读结构体 - 不要用
WithValue传业务逻辑参数（如订单 ID、用户权限），它只适合请求级元数据（traceID、userID、locale）；业务参数请走函数参数
调试 context 是否生效，别靠猜
线上出问题时，最可靠的验证方式只有两个：
- 在关键位置加日志：
log.Printf("ctx.Err() = %v", ctx.Err())，看是不是context.Canceled或context.DeadlineExceeded - 用
pprof查 goroutine 堆栈：curl http://localhost:6060/debug/pprof/goroutine?debug=2，搜索select { case 是否卡在阻塞状态
GoLand 的 debugger 可以看到 ctx 的具体类型（比如 *timerCtx）、Done() 通道是否已关闭，但看不到它是否被正确监听——那得看你代码里有没有真正的 select 或 if ctx.Err() != nil 判断。
