GoLand 不会自动生成 context 相关代码，必须手动创建、传递、监听和取消；HTTP handler 中须用 req.Context() 而非 Background()，数据库/gRPC/client 调用需显式传 ctx，goroutine 启动时应显式传入 ctx，WithValue 的 key 必须是全局唯一变量而非字符串字面量。
GoLand 不会、也不能生成 context 相关的代码文件——context 不是模板或骨架，它必须由你手动创建、传递、监听和取消。IDE 只能辅助写法（比如补全 WithTimeout），但不会自动生成一个「带 context 的 handler 文件」或「含 cancel 调用的 goroutine 封装」。
真正卡住人的，从来不是“怎么敲”，而是“在哪儿加、加完要不要检查、漏了会怎样”。下面直说几个高频实操点。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
HTTP handler 里怎么拿 context？别用 Background()
所有 HTTP 入口必须从 *http.Request 拿，而不是自己 new：
- ✅ 正确：ctx := req.Context()
- ❌ 错误：ctx := context.Background() 或 context.TODO()
漏掉这一步，后续所有 db.QueryContext(ctx, ...)、http.Client.Do(req.WithContext(ctx)) 都失效，超时/取消完全不起作用。
数据库和 client 调用必须显式传 ctx 参数
常见错误是沿用老写法，直接调 db.Query(...) 或 client.Do(req)：
- db.Query() → 必须换成 db.QueryContext(ctx, ...)
- http.Client.Do(req) → 必须改成 http.Client.Do(req.WithContext(ctx))
- gRPC client 方法如 client.GetUser(ctx, req)，漏传 ctx 就等于放弃上下文控制
这些不是 GoLand 能自动替换的，IDE 不会提示你“这里该加 ctx”，也不会警告你用了非 Context 版本。
启动 goroutine 时不能闭包捕获外层 ctx
尤其当外层 ctx 是局部变量（比如 handler 里的 req.Context()）时：
- ❌ 危险写法：go func() { doSomething(ctx) }() —— 如果 handler 返回、ctx 被 cancel，goroutine 仍可能持有已失效的引用
- ✅ 安全写法：go func(ctx context.Context) { doSomething(ctx) }(req.Context())，或更清晰地：ctx := req.Context(); go doSomething(ctx)
GoLand 不会检测这种闭包捕获风险，也不会建议你“把 ctx 显式传进去”。
WithValue 的键必须是全局唯一变量，别用字符串字面量
这是线上排查最头疼的一类问题：
- ❌ 错误：ctx = context.WithValue(ctx, "user_id", 123) —— 不同包里同名字符串被视作不同 key，Value("user_id") 拿不到值
- ✅ 正确：定义全局 key 变量，比如 type userIDKey int; const userIDKey = iota，再用 context.WithValue(ctx, userIDKey, 123)
- 值也不能传 map 或 slice，因为 Value() 返回副本引用；真要传，得用指针或只读结构体封装
GoLand 的类型提示对 WithValue 的 key 类型毫无约束力，它不会阻止你传字符串，也不会提醒你 key 冲突。
复杂点在于：context 的有效性不靠编译检查，而靠你每一步是否显式透传、是否及时 cancel、是否避免 value 泄漏。GoLand 能做的，只是帮你少打几个字母；剩下的，得靠你在每个函数签名、每次调用、每个 goroutine 启动处，亲手确认。
