最直接方法是配置http.Client的Timeout和Transport各阶段超时；下载大文件需用context.WithTimeout控制io.Copy；临时文件应先写入再重命名；重定向需注意context继承或禁用自动跳转。
用 http.Client 设置超时最直接
Go 标准库的 http.Client 本身支持超时控制，不需要额外封装或第三方库。关键不是给整个请求加 time.Sleep，而是让底层连接、读写、重定向都受控——否则可能卡在 DNS 解析或 TCP 握手阶段就永远等下去。
常见错误是只设 Timeout 字段，但这个字段只作用于“整个请求生命周期”，不区分阶段；更稳妥的做法是分别设置 Transport 的各阶段超时：
-
Timeout：总耗时上限（含 DNS、连接、TLS、发送、接收） -
Transport.DialContext：控制 DNS + TCP 连接时间 -
Transport.TLSHandshakeTimeout：单独限制 TLS 握手 -
Transport.ResponseHeaderTimeout：从发完请求到收到响应头的时间 -
Transport.ExpectContinueTimeout：100-continue 等待时间（一般不用改）
多数场景下，设 Timeout 就够用；但如果要精细控制（比如允许慢连接但拒绝慢响应），就得配 Transport。
io.Copy 下载大文件时必须配合 context.WithTimeout
HTTP 请求发出去了，但服务器迟迟不返回 body，或者返回巨长的流式响应，io.Copy 会一直阻塞。这时仅靠 http.Client.Timeout 不一定生效——因为响应头已收到，Client 认为“请求成功”，后续读取交给用户代码。
正确做法是在调用 io.Copy 前，用 context.WithTimeout 包一层，并把 context 传给 http.NewRequestWithContext，确保整个生命周期可取消：
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := client.Do(req)
if err != nil {
return err // 可能是 context.DeadlineExceeded
}
defer resp.Body.Close()
// 此处 io.Copy 也会响应 ctx 取消
_, err = io.Copy(dst, resp.Body)
注意：io.Copy 本身不感知 context，但它读的 resp.Body 是带 cancel 能力的（底层基于 net/http.http2transport 或 http.Transport 实现），所以只要 request 是 context-aware 的，body 读取就会中断。
下载中断后临时文件要清理
超时发生时，文件可能已写入部分字节，但没完成。如果下次还用同一个路径，会出现“残缺文件覆盖失败”或“静默续传”问题（实际并没有断点续传逻辑）。
安全做法是：先写入临时文件（如 filename.tmp），只有完整下载且校验通过后，再 os.Rename 成目标名。中断时删掉临时文件：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
defer os.Remove(tmpPath)开头就注册清理，但得确保它只在失败时触发（可用err != nil判断后显式删） - 避免用
os.Create直接打开目标路径——一旦写一半崩溃，用户看到的就是损坏文件 - 不要依赖
os.RemoveAll清目录，临时文件名建议加随机后缀（如fmt.Sprintf("%s.%s.tmp", base, randStr())），防止并发冲突
这不是 HTTP 层的事，但和超时强相关：超时越频繁，残留临时文件越多，不处理就会堆积。
重定向和 302 响应容易绕过超时
默认 http.Client 会自动跟随重定向（CheckRedirect 返回 nil），但每次跳转都会新建请求，而新请求不会继承原 request 的 context——除非你手动控制重定向逻辑。
后果是：第一次请求 5 秒超时，跳转后第二次请求又卡住 5 秒，总耗时翻倍还不报错。
解决方法有两种：
- 禁用自动跳转：
client.CheckRedirect = func(req *http.Request, via []*http.Request) error { return http.ErrUseLastResponse }，然后自己用同一个 context 处理跳转后的req - 保持自动跳转，但给
client设置全局Timeout，并确保它足够覆盖所有可能跳转次数的累计耗时
后者简单，但不精确；前者可控，但要自己解析 Location header 并构造新 request。实践中，如果服务端跳转链稳定（≤2 次），设一个宽松的总 Timeout 更省事。
真正麻烦的是服务器返回 302 后故意延迟响应头，或者重定向到一个不可达域名——这时候 DNS 阶段就卡死，必须靠 Transport.DialContext 里的 net.Dialer.Timeout 拉回来，光靠 Client.Timeout 挡不住。
