Go net/http.NewRequestWithContext 如何绑定请求取消：构造顺序、nil context 与客户端验证

给 Go 服务加超时或取消请求时，最容易埋下的坑不是 context.WithTimeout，而是请求创建的位置：如果先用 http.NewRequest 再在别处保存 context，取消信号并不会自动进入这一个 request。http.NewRequestWithContext 把两者绑定在构造阶段，客户端执行时才能沿着同一条调用链结束请求。

先把取消发生在哪里跑出来

下面的示例启动一个只延迟 200 毫秒的测试服务器，然后分别验证两条路径：第一条在 client.Do 前主动取消，第二条让 30 毫秒超时在请求过程中触发，最后故意传入 nil 检查构造边界。这里的父类型可以明确写成 context.Context，服务端和客户端输出都来自同一次运行。

ctx, cancel := context.WithCancel(context.Background())
request, err := http.NewRequestWithContext(ctx, http.MethodGet, server.URL, nil)
cancel()
_, err = client.Do(request)
fmt.Println(errors.Is(err, context.Canceled), err)

这里不要只看布尔值。errors.Is 判断的是错误链，后面的具体错误文本还能帮助日志定位；如果只比较字符串，换一层 HTTP 包装后就容易误判。

构造顺序决定取消信号能否抵达 Do

第二次请求把 30 毫秒的 deadline 传给 NewRequestWithContext，而测试服务需要 200 毫秒才会返回。请求还没有读到响应体，context 就先关闭了连接路径，客户端输出应当能匹配 context.DeadlineExceeded。

deadlineCtx, deadlineCancel := context.WithTimeout(context.Background(), 30*time.Millisecond)
defer deadlineCancel()
request, err = http.NewRequestWithContext(deadlineCtx, http.MethodGet, server.URL, nil)
_, err = client.Do(request)
fmt.Println(errors.Is(err, context.DeadlineExceeded), err)

三个参数边界，按调用场景做选择

请求通常只服务一次调用，因此应把 request 和它的 context 一起创建。若需要重试，每次重试都要重新计算剩余时间并构造新的 request；继续使用已取消的 request，只会得到一个看似随机、实际已经确定的取消错误。

常见问题

NewRequestWithContext 传 nil 会怎样？

它会返回错误，调用方应先选择明确的父 context；不要把 nil 当成无限超时的快捷写法。

context.Canceled 和 DeadlineExceeded 有什么区别？

前者通常表示主动取消，后者表示 deadline 到期。生产日志可以用 errors.Is 分开计数。

为什么还要检查 client.Do 的错误？

context 只负责发出取消信号，网络连接、DNS 或服务端也可能先失败，最终错误仍必须由 Do 返回值判断。

把验证动作留在请求边界

这组输出证明的是调用链，而不是“设置了一个超时数字”：context 在请求构造处进入 request，Do 再把取消状态传给 Transport，客户端最终以可判定的错误类型返回。把 NewRequestWithContext 放在真正发起一次请求的函数里，取消、超时和重试的边界会更清楚。