context 通过信号传递实现优雅超时与取消，不直接终止 Goroutine；需用 WithTimeout 创建并透传上下文，调用 cancel 防泄漏，I/O 操作须检查 ctx.Err() 并手动监听取消做清理。
在 Go 中，context 是控制请求生命周期（尤其是超时与取消）的核心机制。它不直接“杀死” Goroutine，而是通过传递信号，让被调用方主动退出，从而实现优雅的超时控制和资源清理。
使用 context.WithTimeout 控制 HTTP 请求超时
HTTP 客户端默认没有超时限制，容易导致连接堆积或长时间阻塞。应显式传入带超时的 context.Context：
- 创建超时上下文：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) - 务必在使用后调用
cancel()，避免内存泄漏（可用defer cancel()） - 将
ctx传给http.NewRequestWithContext(ctx, ...)，而非旧版NewRequest - HTTP 客户端会自动监听该上下文：一旦超时，请求立即中止，底层连接会被关闭
嵌套调用中传递并延续超时信号
服务 A 调用服务 B，B 又调用数据库或下游服务时，需把原始超时上下文向下透传，确保整条链路受统一时限约束：
- 不要在中间层新建独立超时（如
WithTimeout(ctx, 2*time.Second)），除非有明确的子任务 SLA - 若需为某子操作单独设限，可用
context.WithTimeout(parentCtx, ...)，但记得仍从父 ctx 派生，保持取消传播 - 所有 I/O 操作（DB 查询、RPC、文件读写）都应接收
ctx参数，并在内部检查ctx.Err() != nil提前返回
手动监听取消信号做清理
不是所有操作都原生支持 context（比如自定义阻塞逻辑、长轮询、第三方库无 ctx 接口）。这时需主动监听：
立即学习“go语言免费学习笔记（深入）”；
- 用
select { case 等待取消通知 - 在
case 分支中释放资源：关闭文件、断开连接、停止 goroutine - 注意：
ctx.Err()在取消后才非 nil，且只返回一次；多次调用安全，但不能用来“重置”上下文
避免常见陷阱
几个高频出错点：
- 不要把 context 当作数据容器存业务参数 —— 它专为取消/超时设计，传参请用函数参数或结构体
- 不要忘记调用 cancel() —— 即使超时已触发，显式 cancel 仍能提早释放关联的 timer 和 goroutine
- 不要用 background 或 todo context 做实际请求 —— 它们无法被取消，会使超时逻辑失效
- 测试超时场景时，可用
context.WithCancel手动触发取消，比等真实超时更可靠
基本上就这些。context 超时不是魔法，关键在于每一层都尊重并传递信号，配合及时的资源清理，才能真正实现可控、可测、可维护的请求生命周期管理。
