微服务中context控制生命周期需各环节响应ctx.done()，否则导致泄漏、超时失效；http.request.context()不可直传后台goroutine，应派生新context或用context.background()；withtimeout计时始于调用完成；goroutine必须显式监听ctx.done()；cancel()应由启动方在明确终止时机调用且仅一次。
微服务里用 context 控制生命周期，不是“加个参数就完事”，而是必须让每个关键环节都响应 ctx.Done()，否则照样泄漏、超时无效、重启卡死。
为什么 http.Request.Context() 不能直接传给后台 goroutine？
HTTP handler 接收的 r.Context() 是请求级上下文，它会在客户端断开或响应写完后自动取消。但如果你把它直接传给一个长期运行的后台任务（比如发消息、写日志、轮询状态），这个 goroutine 就会随请求结束被意外终止——哪怕业务上它本该继续跑。
常见错误现象：后台任务中途退出、消息没发完、状态同步中断。
- 正确做法是用
context.WithCancel(r.Context())派生新 context，并在业务逻辑完成时主动调用cancel() - 若任务需脱离请求生命周期独立存在，应改用
context.Background()起始，再手动控制其取消边界 - 永远别把
r.Context()当作“万能取消源”塞进异步任务里
context.WithTimeout 的超时时间从哪一刻开始算？
从调用 context.WithTimeout() 那一行代码执行完毕开始计时，不是从 goroutine 启动、也不是从 HTTP 请求到达、更不是从数据库连接建立时开始。
这意味着：如果在 WithTimeout 之后还做了大量初始化（如加载配置、建连接池、解密 token），真正留给核心逻辑的时间会少于预期。
- 实操建议：把
WithTimeout尽量靠近实际 I/O 操作前，比如在调用http.Do()或db.QueryRow()前才创建 - 避免在 for 循环里反复调用
WithTimeout，每次都会新建 timer，GC 压力明显上升 - 若需“整条链路总耗时限制”，应在入口统一设置，子调用复用同一
ctx，而非各自设超时
子 goroutine 不监听 ctx.Done() 就等于没用 context
context 不会强制杀死 goroutine，它只发信号。你看到 ctx.Err() == context.Canceled，不代表那个 goroutine 已退出——它可能还在 for 循环里跑、还在读 channel、还在等锁。
典型泄漏场景：启动一个 goroutine 去轮询，但忘记在 select 中监听 ctx.Done()，结果服务重启时它还在后台刷日志。
- 所有阻塞操作（
time.Sleep、ch 、<code>、<code>db.Query）前后，都应检查ctx.Err()或参与select - 不要只靠
if ctx.Err() != nil判断，这无法捕获正在阻塞中的 goroutine；必须用select { case - 第三方库（如
sqlx、redis-go）若支持 context，优先传入；不支持的，需自己包装超时逻辑
cancel() 函数该在哪儿调用、调几次？
cancel() 是一次性开关，调一次就关闭 ctx.Done()，重复调用无害但暴露设计问题——说明你不清楚谁该负责取消。
最容易踩的坑：在 defer 里调 cancel()，但函数提前 return 了，导致 cancel 没触发；或者多个 goroutine 竞争调用同一个 cancel()，逻辑混乱。
- 推荐模式：由启动 goroutine 的那一方持有
cancel，并在明确知道任务该结束时（如主流程完成、收到错误、超时）调用 - 绝不在 goroutine 内部 defer
cancel()，除非你能 100% 确保它只在自己生命周期内生效 - 禁止把
cancel函数传给不可控的第三方库，除非文档明确说它会调用且只调一次
最常被忽略的一点：context 的层级关系是单向的，父 cancel 会级联子 cancel，但子 cancel 不影响父。所以你在微服务里嵌套调用时，得想清楚——是让整个请求链一起停，还是只停某一段下游依赖。这个判断一旦错了，要么停不干净，要么停过头。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
