Context必须作为函数首个参数显式传入，因Go生态约定、强制上下文感知、避免信号中断、符合标准库及框架规范，并需在goroutine启动时手动传递以确保取消和超时信号透传。
context.Context 必须作为函数首个参数显式传入，不能靠框架自动注入或隐式获取；否则子 goroutine 无法感知取消、超时等信号，极易引发资源泄漏和响应延迟。
为什么Context要放在函数第一个参数位置
Go 标准库（net/http、database/sql、gRPC 等）全部约定 context.Context 是首参，这是生态共识，不是风格偏好。框架如 Gin、Echo、Chi 在中间件和 handler 中也严格遵循这一约定。
把 Context 放在首位能强制开发者意识到“这个调用是受上下文控制的”，避免漏传。一旦位置错乱（比如塞在中间或末尾），下游函数调用链中极易断掉信号传递。
- HTTP handler 签名必须是
func(http.ResponseWriter, *http.Request)，但实际业务逻辑应写成func(ctx context.Context, ...)，由中间件从*http.Request提取req.Context()后传入 - 如果封装了数据库操作函数，签名应为
func(ctx context.Context, query string, args ...any)，而不是func(query string, ctx context.Context, ...) - IDE 和 linter（如
staticcheck）会检查context.Context是否为首个参数，错位会直接报SA1012警告
WithValue 传请求元数据的正确姿势
context.WithValue 只适合传不可变的、请求级只读元数据（如 userID、traceID、authScope），且 key 必须是自定义类型，不能用 string 或 int 直接当 key —— 否则跨包冲突风险极高。
- 定义 key 类型：
type userIDKey struct{}，然后用ctx = context.WithValue(ctx, userIDKey{}, 123) - 取值时务必做类型断言并判空：
if id, ok := ctx.Value(userIDKey{}).(int); ok { ... } - 不要用
WithValue传结构体指针或切片，多个 goroutine 并发读写会触发竞态；如需共享状态，改用独立的 sync.Map 或传拷贝后的值 - 框架中间件里设值后，下游 handler 必须从入参
ctx取，而不是重新从req.Context()拿——因为中间件可能已派生新 ctx
goroutine 启动时 Context 必须手动传入
父 goroutine 创建的 Context 不会自动透传到子 goroutine。spawn 新 goroutine 时，必须显式把当前 ctx 作为参数传进去，否则子 goroutine 完全收不到取消或超时信号。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
go doWork()（doWork内部自己调context.Background()） - 正确写法：
go doWork(ctx)，且doWork函数签名含ctx context.Context - 若子 goroutine 还要派生新 Context（如加超时），必须基于传入的
ctx派生，而不是context.Background()，否则父子生命周期脱钩 - 在子 goroutine 内部，所有阻塞操作（如
time.Sleep、ch 、<code>db.QueryRowContext）都应监听ctx.Done()，不能只依赖外部 cancel
defer cancel() 的坑：别在 handler 入口就 defer
cancel 函数必须在它所创建的 Context 生命周期结束时调用，但绝不等于“在 handler 开头 defer cancel()”就万事大吉。
- 如果 handler 中启动了长期运行的子 goroutine（如日志上报、异步通知），而你在入口
defer cancel()，那子 goroutine 很可能在父 ctx 取消后还继续跑，甚至 panic（因访问已关闭的ctx.Done()） - 更安全的做法：对需要延长生命周期的操作，用
context.WithCancel(ctx)派生子 ctx，并在子 goroutine 结束时单独调cancel() - HTTP handler 中，标准做法是直接用
req.Context()，不自行WithCancel；只有在需要额外控制（如限制某段逻辑超时）时才派生，且cancel调用时机要和业务逻辑终点严格对齐
ctx, cancel := context.WithTimeout(...)，而是确保整条调用链上每个函数都把它当作「第一公民」来对待——传、用、监听、清理，缺一不可。一个环节松动，整个请求的生命周期控制就失效。 
