context必须显式作为首参数传递，因go无隐式上下文继承，不传则超时、取消、traceid全部丢失；所有i/o函数应以func(ctx context.context, ...)开头，goroutine启动也须显式传入，否则脱离生命周期管理。
Context 不能靠全局变量或中间件自动透传，必须显式传递到每个可能阻塞或需要取消的函数调用中 —— 否则超时、取消、日志 traceID 都会丢失。
为什么 context.Context 必须作为第一个参数显式传入
Go 的 context 不是线程/协程绑定的隐式上下文（不像 Java 的 ThreadLocal），它纯粹是值传递。一旦你在某层函数里没接收 ctx，后续所有子调用就彻底断连。
- 常见错误：HTTP handler 里用
req.Context()创建了新ctx，但调用下游 service 方法时没把ctx传进去，导致下游无法响应 cancel - 正确姿势：所有可能涉及 I/O、重试、sleep、数据库查询、HTTP 调用的函数签名，都应以
func(ctx context.Context, ...)开头 - 不传
ctx的后果：超时后 handler 已返回，但 goroutine 仍在跑 DB 查询；分布式 trace 断链；pprof 标记失效
如何安全地从 HTTP 请求注入并向下传递 context.Context
别在中间件里用 context.WithValue 往 http.Request 塞自定义 key —— Go 官方明确反对这种用法，且 req.Context() 本身已提供标准入口。
- 入口统一用
req.Context()：在 handler 或 Gin/Echo 的中间件里直接取c.Request.Context()（Gin）或r.Context()（net/http） - 向下传递时优先用派生：比如加超时用
context.WithTimeout(ctx, 5*time.Second)，加 value 用context.WithValue(ctx, key, val)，但 value key 必须是私有 unexported 类型（避免冲突） - 禁止覆盖原
ctx：不要写ctx = context.WithValue(req.Context(), ...)后又丢掉原始req.Context()，否则 cancel 信号中断
context.WithCancel 和 context.WithTimeout 在微服务调用链中的典型误用
很多人以为在 client 层调用 context.WithTimeout 就够了，其实下游服务如果自己又套了一层 timeout，会导致嵌套超时不可控，甚至提前 cancel。
- 推荐做法：上游只设合理总超时（如 3s），下游 service 方法内部不再额外设 timeout，而是信任上游 ctx 的 deadline
- 慎用
context.WithCancel：手动 cancel 容易漏 defer 或重复 cancel，除非你明确需要“主动终止”逻辑（如用户取消订单），否则优先依赖超时或父 ctx 自动 cancel - 注意 deadline 传播：HTTP 客户端（如
http.Client）会自动读取ctx.Deadline()并设置底层连接超时，但 gRPC client 需要显式传ctx到Invoke或SendMsg
跨 goroutine 传递 context.Context 的边界与风险
goroutine 启动时若未传入 ctx，它就脱离了整个请求生命周期管理 —— 即使父 goroutine cancel，它也不会停。
- 必须传：启动 goroutine 时，
go doWork(ctx, ...)，而不是go doWork(...) - 必须检查：在 goroutine 内部循环中，定期用
select { case 检查退出信号 - 警惕 “ctx done but resource not closed”：比如 goroutine 持有 DB 连接或文件句柄，cancel 后需显式 cleanup，不能只靠 ctx 通知
- logrus/zap 日志库支持
ctx注入 traceID，但需确保每条日志都通过logger.WithContext(ctx).Info(...)调用，否则 trace 断在某一层
最常被忽略的一点：context.Context 是不可变的，但它的 Done() channel 可被多个 goroutine 并发读 —— 所以不用加锁，但也不能在 goroutine 里修改它本身（比如重新赋值）。传错一层，整条链就哑火。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
