go 1.7+ 必须用标准库 context 替代 x/net/context，删除所有 golang.org/x/net/context 导入并替换为 context，确保类型兼容、api 一致，升级依赖消除间接引用，避免 cannot use context.withcancel() as x/net/context.context 等类型不匹配错误。
Go 语言里不存在“向后兼容传递旧版本 Context 数据”这种需求——context.Context 本身没有版本号，标准库自 Go 1.7 起就已统一，所谓“旧版本”只可能是项目里残留的 golang.org/x/net/context，而它和标准库 context 是类型不兼容的。
为什么你看到的 context 类型报错其实是 x/net/context 残留
常见错误如 cannot use context.WithCancel() (value of type context.Context) as x/net/context.Context，根本原因不是 API 变了，而是两种包混用导致类型系统拒绝赋值。标准库 context 和 x/net/context 的 Context 接口虽然长得一样，但属于不同包、不同类型，Go 不认作同一类型。
- 全局搜索并删掉所有
import "golang.org/x/net/context"，替换成import "context" - 检查
go.mod里有没有间接依赖还在拉x/net/context；用go list -f '{{.Deps}}' your/module | grep x/net/context找出源头 - 第三方库若未升级，别硬改 import，优先换库或提 PR；fork 后手动替换也要确保所有
.Done()、.Err()调用都指向标准库方法，别碰私有字段（如ctx.(*cancelCtx).done）
Context 值传递本身没有“版本兼容”问题，但 key 冲突会静默覆盖
context.WithValue 的值能否被下游拿到，和 Go 版本无关，只取决于 key 是否匹配、ctx 是否显式传入。但用 string 当 key 时，不同包定义的 "user_id" 会互相覆盖，看起来像“旧数据丢了”。
- 必须用未导出空 struct 当 key：
type userIDKey struct{}，而不是type userIDKey string或直接"user_id" - 存取必须严格配对：
ctx = context.WithValue(ctx, userIDKey{}, id)→id := ctx.Value(userIDKey{}).(int64) - IDE 能跳转到 key 定义，编译器能检查类型，拼错
userIDKey{}就报错，不会运行时返回nil
HTTP handler 中 context 透传失败，往往是因为没重绑定 Request
中间件里修改了 ctx（比如加了 traceID 或超时），但忘了调用 r = r.WithContext(newCtx)，下游 handler 拿到的还是原始 r.Context()，误以为“旧 context 数据没传过去”。
- 中间件函数结尾必须写
next.ServeHTTP(w, r.WithContext(newCtx))，不能只改局部变量ctx - 不要在 handler 里缓存
req.Context()到 struct 字段，goroutine 泄漏和取消失效大概率从这儿开始 - DB 查询等 I/O 操作必须用
QueryContext(ctx, ...)，而非Query(...)；否则 context 信号根本进不去驱动层
真正容易被忽略的是：context 一旦派生，就和父 ctx 绑定生命周期；你不能靠“兼容旧数据”来绕过设计约束——业务字段该走函数参数就走参数，该走 HTTP header 就走 header，context 只负责信号和轻量元数据。强行往里塞订单 ID 或用户邮箱，迟早遇到类型断言失败、可读性崩坏、测试难写的问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
