context 需通过明确用途驱动、小步验证和避开误用惯性掌握；必须用 context.withcancel 的场景是启动可能被外部中断的 goroutine，如 http 请求中断或用户取消，此时应传入带 cancel 的子 context 而非仅用 sync.waitgroup。
context 不是靠“语言学习方法”掌握的，它是靠明确用途驱动 + 小步验证 + 避开误用惯性掌握的。你不需要背接口定义，也不用从“Context 是什么”开始学——直接从你正在写的代码里找那个卡住的 goroutine，它就是上下文该出场的地方。
什么时候必须用 context.WithCancel？
当你启动了一个 goroutine，且它可能被外部中断（比如 HTTP 请求被客户端断开、用户点了取消按钮、父任务提前结束），就必须用 context.WithCancel。
- 错误做法：用
sync.WaitGroup等它自己跑完 —— 它可能永远不结束，资源就卡死了 - 正确做法：传入一个带 cancel 的子 context，goroutine 内部监听
- 关键细节：
cancel()必须在所有可能路径上被调用（包括 defer、error return、success return），否则子 context 永远不会释放
context.WithTimeout 和 context.WithDeadline 怎么选？
看你是按「持续时间」还是「绝对时间」做约束：
-
context.WithTimeout(ctx, 3*time.Second)：从现在起最多活 3 秒，适合网络请求、数据库查询等相对时间敏感操作 -
context.WithDeadline(ctx, time.Now().Add(3*time.Second))：等价于上面，但显式写出 deadline，适合需要对齐某个全局截止点（如 RPC 链路总超时）的场景 - 注意：
WithTimeout底层就是调用WithDeadline，两者行为一致；但别混用：不要用WithTimeout去模拟“下午 3 点前必须完成”的业务逻辑，那得用WithDeadline
为什么 context.WithValue 容易出问题？
它不是用来传参数的，而是用来传「请求范围的元数据」——而且必须满足两个条件：轻量、只读、跨层透传。
- 典型安全用法：
ctx = context.WithValue(ctx, "request_id", "abc123")，后续所有日志、trace、metrics 都能拿到这个 ID - 危险用法：
context.WithValue(ctx, "user", &User{...})—— 如果 User 结构体很大，或后续被修改，会造成内存泄漏或竞态 - 更隐蔽的坑：key 类型用
string会导致冲突（不同包都用"user"当 key），推荐定义私有类型作 key：type userKey struct{}
为什么 ctx 要当第一个参数？
这不是风格问题，是静态分析和工具链依赖的约定。
- Go 工具（如
go vet、staticcheck）会检查是否漏传ctx，前提是它在首位 - HTTP 中间件、gRPC 拦截器、SQL 查询函数（如
db.QueryRowContext）都强制要求ctx在第一位 - 如果写成
func DoX(arg string, ctx context.Context)，不仅难被工具识别，还会让调用方下意识忽略它——而它恰恰是最不该被忽略的参数
真正卡住人的，从来不是 context 的 API，而是忘记它本该解决的问题：谁来决定这个 goroutine 该停？什么时候停？停了之后怎么清理？ 把这三个问题贴在你正在写的函数上方，再决定要不要加 ctx context.Context 参数。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
