必须用 context.WithTimeout 全链路注入并传递，否则 http.Client.Timeout 无法中断 DNS 解析、TLS 握手、流式响应读取等环节；需通过 http.NewRequestWithContext 显式传入上下文，并用 errors.Is(err, context.DeadlineExceeded) 判断超时。
Go 服务调用 Composer 镜像源（如 https://packagist.org 或私有镜像）时，单纯靠 http.Client.Timeout 无法可靠中断 DNS 解析、TLS 握手或流式响应读取——必须用 context.WithTimeout 全链路注入并传递，否则超时形同虚设。
为什么 http.Client.Timeout 对 Composer 请求不够用
Composer 的典型请求是 GET /packages.json 或 POST /search，常含重定向、Gzip 响应体、分块传输。标准 http.Client.Timeout 只覆盖“从 Do() 开始到收到完整响应”这一段，但以下环节它管不了：
- DNS 查询卡住（尤其在容器内 /etc/resolv.conf 配置不当）
- TLS 握手因证书链验证慢或中间 CA 不可达而阻塞
- 服务端流式返回大体积
packages.json，但首字节已返回，Timeout不触发 - 重定向跳转后新建请求，旧
Timeout不继承
这些场景下，context.WithTimeout 才能真正中断底层 net.Conn 和 http.Transport 的阻塞调用。
context.WithTimeout 必须在 http.NewRequestWithContext 中显式传入
常见错误是只改 Client，没改 Request：
立即学习“go语言免费学习笔记（深入）”；
// ❌ 错误：只设 Client 超时，没传 context 到 request
client := &http.Client{Timeout: 5 * time.Second}
req, _ := http.NewRequest("GET", "https://www.php.cn/link/6060b7fe96c78f32d3a8c14897f1af61", nil)
resp, err := client.Do(req) // DNS/TLS 卡住时仍会 hang
<p>// ✅ 正确：用 WithTimeout 创建 ctx，并通过 NewRequestWithContext 注入
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
req, _ := http.NewRequestWithContext(ctx, "GET", "<a href="https://www.php.cn/link/6060b7fe96c78f32d3a8c14897f1af61">https://www.php.cn/link/6060b7fe96c78f32d3a8c14897f1af61</a>", nil)
resp, err := client.Do(req) // 全链路可中断
关键点：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
http.NewRequestWithContext是唯一能将ctx绑定到本次请求生命周期的方式 -
cancel()必须调用，即使请求已完成——避免 goroutine 泄漏（context内部 timer 未清理） - 不要复用同一个
ctx发多个请求；每个请求应有独立ctx实例
下游代理（Nginx / Traefik）和 Composer 客户端本身的超时也要对齐
Go 服务作为 Composer 镜像代理时，超时必须逐层收敛，否则上层超时失效：
- Nginx 层：设
proxy_connect_timeout 3s、proxy_read_timeout 5s，否则请求卡在反向代理就进不了 Go 进程 - Go 服务层：用
context.WithTimeout(r.Context(), 4*time.Second)，比 Nginx 少 1 秒，留出转发开销 - Composer 客户端（PHP 侧）：设
"repositories": [{"type": "composer", "url": "http://your-go-proxy/"}]，并确保其config.json中"process-timeout": 30不压倒 Go 层限制
若 Go 层设 4s，但 Composer 客户端设了 60s 超时，用户看到的仍是 60s 卡顿——因为 PHP 进程还在等 Go 返回，而 Go 已提前断连，导致 HTTP 502 或空响应。
超时错误判断必须用 errors.Is(err, context.DeadlineExceeded)
不能靠字符串匹配或 err == context.DeadlineExceeded，因为 http.Client.Do 返回的是包装后的 error：
resp, err := client.Do(req)
if err != nil {
// ❌ 错误：直接比较会失败
if err == context.DeadlineExceeded { ... }
<pre class="brush:php;toolbar:false;">// ✅ 正确：用 errors.Is 判断底层是否为 DeadlineExceeded
if errors.Is(err, context.DeadlineExceeded) {
log.Warn("Composer mirror timeout")
http.Error(w, "镜像源响应超时", http.StatusGatewayTimeout)
return
}}
另外注意：ctx.Err() 在超时后返回 context.DeadlineExceeded，但 http.Client.Do 的 error 是另一条路径——二者不等价，必须检查 Do 的返回值。
最易被忽略的一点：Composer 请求常带 Accept-Encoding: gzip，而 Go 的 http.Transport 默认解压响应体。如果服务端返回巨量 gzip 数据，解压过程本身不响应 context 取消——此时需配合 io.LimitReader 或提前校验 Content-Length 做防护，否则超时机制在解压阶段失效。
