context.WithTimeout不能直接套在goroutine启动处，因其返回的ctx和cancel是独立对象，goroutine内未监听ctx.Done()则超时无法中断；必须显式传入ctx并在阻塞点如http.Do、time.Sleep、channel操作中检查Done()。
为什么 context.WithTimeout 不能直接套在 goroutine 启动处？
因为 context.WithTimeout 返回的 ctx 和 cancel 是独立对象，goroutine 内部若没主动监听 ctx.Done()，超时根本不会中断它——Go 不会强制杀协程。
常见错误现象：调用 context.WithTimeout 后启动 goroutine，主函数等 timeout 到了就返回，但后台 goroutine 仍在跑、资源未释放、甚至 panic 报 send on closed channel。
- 必须把
ctx显式传入 goroutine 执行逻辑中，且在关键阻塞点（如http.Do、time.Sleep、ch ）前检查ctx.Err() != nil - 如果 goroutine 自己启了子 goroutine，要传递
ctx而不是复用父级context.Background()，否则取消信号断链 -
cancel()必须在超时后或提前完成时调用，否则底层 timer 不释放，可能引发内存泄漏（尤其高频创建场景）
如何让多个 goroutine 共享同一个取消信号？
靠 context 的父子继承机制：所有子 goroutine 都接收同一个 ctx（或由它派生的 childCtx），只要父 ctx 被 cancel，所有监听它的 goroutine 都能同时收到 ctx.Done() 关闭信号。
使用场景：一个 HTTP handler 启动了数据库查询、缓存写入、日志上报三个并发操作，任一失败或超时，其余都该立即退出。
立即学习“go语言免费学习笔记（深入）”；
- 不要每个 goroutine 自己调
context.WithCancel(context.Background())—— 这样它们互不感知 - 正确做法是 handler 入口统一创建
ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)，再把ctx分别传给各子逻辑 - 注意
r.Context()已带 HTTP 生命周期绑定，应以此为根，而非硬写context.Background()，否则请求中断时你的 goroutine 还在跑
ctx.Done() 触发后，为什么还要手动 close channel 或 return？
因为 ctx.Done() 只是一个通知通道（），它不会自动终止你的代码执行流，也不关闭你打开的资源。
常见错误现象：监听到 ctx.Done() 后继续往已关闭的 channel 发送数据，或没清理 sql.Rows 导致连接泄漏。
- 典型模式是：
select { case ，必须显式return或break - 如果用了
for range ch，需配合if ctx.Err() != nil { break }，因为 range 不感知 context - 涉及文件、DB 连接、HTTP body 等资源，必须在
ctx.Done()分支里加defer或显式Close()，不能依赖 defer 在函数退出时才执行（它可能永远不退出）
为什么嵌套 context.WithTimeout 容易导致时间计算错乱？
每个 WithTimeout 都从当前系统时间开始计时，不是从父 context 的 deadline 继承。嵌套两层 3s timeout，实际最长可能跑 6s。
性能影响：多层 timer 堆积增加调度开销；兼容性问题：某些中间件（如 grpc-go）会覆盖或透传 context，自行嵌套可能和框架行为冲突。
- 避免
ctx2 := context.WithTimeout(ctx1, 3*time.Second)这种写法，除非你明确需要“额外追加”超时 - 多数情况应复用上游传入的
ctx，仅调context.WithValue增加数据，而不是重设 deadline - 如真需分阶段超时（比如总耗时 5s，其中 DB 查询最多 2s），用
context.WithDeadline手动算好绝对时间点，而非套娃WithTimeout
最常被忽略的一点：父 context 被 cancel 后，子 context 的 Done() 会立即关闭，但子 context 自己创建的 timer 不会自动 stop——所以嵌套 timeout 不仅逻辑错，还浪费资源。
