Go语言之Context取消机制详解：语言学习中的并发请求控制-Golang-PHP中文网

http请求取消必须用http.newrequestwithcontext，因transport只监听构造时注入的context；手动赋值req.context无效，因其仍为background且不被识别。

go语言之context取消机制详解：语言学习中的并发请求控制

HTTP 请求的取消必须靠 http.NewRequestWithContext，手动赋值 req.Context 完全无效。

为什么 `http.Client.Do` 不监听你手动设置的 `req.Context`

因为 http.Client 的底层 Transport 只认「构造时注入」的 context。它在请求发起前就注册了对 ctx.Done() 的监听，而这个监听绑定发生在 http.NewRequestWithContext 内部。如果你用 http.NewRequest 创建请求后，再写 req.Context = ctx，Transport 根本不感知——它看到的仍是 context.Background()。

错误写法：req := http.NewRequest("GET", url, nil); req.Context = ctx → 取消永远不生效
正确写法：req := http.NewRequestWithContext(ctx, "GET", url, nil)
即使后端已开始处理，Transport 也会在收到 ctx.Done() 后立即发送 TCP RST 中断连接

多个并发请求共享同一个 `context.Context` 会怎样

所有请求会在该 context 被 cancel 或超时时同步终止，这是设计使然，不是 bug。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。

下载

适合场景：批量 HTTP 请求、并行数据库查询、微服务扇出调用
注意点：共享 context ≠ 请求间有依赖；只是共用一个“总开关”
风险点：如果父 context 被提前 cancel（比如主逻辑误判），所有子请求立刻中断，可能丢结果
别在 goroutine 里 defer 打印日志或关闭资源时依赖 ctx.Err()，因为 cancel 可能发生在 defer 执行前

`context.WithTimeout` 比手写 timer + `cancel()` 更可靠的原因

它把定时器、状态管理、取消幂等性全封装好了，而手写容易漏掉关键环节。

context.WithTimeout 返回的 cancel 函数可重复调用，不会 panic
timer 自动 stop，不用你操心 timer.Stop() 是否执行
goroutine 退出后，cancel 函数仍安全，不会访问已释放内存
多个请求共用一个 timeout context 时，无需额外 channel 或 mutex 协调

取消后怎么区分是用户中断还是业务错误

不能只看 err != nil，必须用 errors.Is(err, context.Canceled) 或 errors.Is(err, context.DeadlineExceeded) 显式判断。

http.Client.Do 在取消时返回的常见错误包括：context canceled、context deadline exceeded、net/http: request canceled
这些都属于控制流信号，不是业务异常，不该重试或记录 error 级日志
尤其注意：某些中间件或 SDK 可能包装错误，需逐层 unwrap 到原始 error 才能准确识别

真正容易被忽略的是：context 的取消传播是树状的，但 cancel 函数本身不是线程安全的——多次调用没问题，但跨 goroutine 触发时，没人帮你加锁。如果你从多个地方同时调用同一个 cancel，虽然不会 crash，但语义上已经失控了。