http.request 本身不支持并发访问，其 close 字段的设置（true/false）不会直接影响并发请求性能，但错误地并发使用同一请求实例会导致未定义行为。
http.request 本身不支持并发访问，其 close 字段的设置（true/false）不会直接影响并发请求性能，但错误地并发使用同一请求实例会导致未定义行为。
在 Go 的 net/http 包中，http.Request 是一个非并发安全（not safe for concurrent use） 的结构体。这意味着：无论你是否修改 Request.Close 字段，只要多个 goroutine 同时读写同一个 *http.Request 实例（例如同时调用 req.Header.Get() 和 req.Body.Read()，或并发修改 req.Close），程序行为即属于未定义（undefined behavior）——可能触发 panic、数据竞争、静默错误，甚至难以复现的偶发崩溃。
Request.Close 字段的作用是向 HTTP 服务端（或客户端底层连接管理器）建议：本次请求完成后是否应关闭底层 TCP 连接。其典型使用场景如下：
-
服务端视角（如 http.HandlerFunc 中）：
req.Close = true 会提示 http.Server 在响应写入完毕后主动关闭连接（绕过 HTTP/1.1 的 keep-alive 机制）。适用于需强制短连接的调试或特殊代理逻辑。func handler(w http.ResponseWriter, req *http.Request) { req.Close = true // 告知服务器：响应后关闭连接 w.WriteHeader(http.StatusOK) w.Write([]byte("Hello")) } 客户端视角（构建 http.Request 时）：
req.Close = true 会阻止 http.Transport 复用连接（即使 Transport.MaxIdleConnsPerHost > 0），每次请求都新建 TCP 连接，显著降低性能，仅应在极少数兼容性场景下使用。
⚠️ 关键注意事项：
- Close 字段不是并发控制开关，它与 goroutine 安全性无关；
- 并发问题的根源在于 *http.Request 的字段（如 Header, Body, URL, Form）被多 goroutine 共享修改；
- 正确做法是：每个 goroutine 应操作独立的请求实例（例如通过 req.Clone(ctx) 创建副本），或确保请求对象生命周期严格限定于单个 goroutine（标准 HTTP handler 即如此）；
- 若需高并发 HTTP 客户端调用，请复用 http.Client，而非复用 *http.Request。
✅ 总结：
不要试图通过 req.Close 来“解决”并发问题；而应遵循 Go 的并发设计哲学——通过共享内存来通信，通过通信来共享内存。HTTP 请求天然是一次性、单 goroutine 生命周期的对象。正确使用 Clone()、避免跨协程传递 *http.Request，才是保障稳定与性能的根本之道。
