Go标准库http.NewRequest返回的*http.Request不可链式调用，因字段如URL、Body不可安全复用，且Header操作非线程安全；正确做法是自定义RequestBuilder值类型，各With方法返回新实例，Build()时才调用NewRequest并注入配置。
为什么直接用 http.NewRequest 写链式构建器会踩坑
Go 标准库的 http.NewRequest 返回的是不可变的 *http.Request，它没有提供类似 .SetHeader() 或 .WithTimeout() 这样的可链式调用方法。硬套链式风格时，容易误以为可以反复修改同一请求对象，结果发现 req.Header.Set() 虽然生效，但 req.URL、req.Body 等字段一旦设置就无法安全复用——尤其在并发场景下，共享 *http.Request 会导致数据竞争或 body 重复读取错误。
真正可行的路径是：自己定义一个可变的构建器类型，在最后一步才调用 http.NewRequest 生成终态请求。中间所有操作（如设 header、query、timeout）都只修改构建器字段，不碰真实 *http.Request。
如何设计一个线程安全、可复用的 RequestBuilder
核心是把“待构建状态”和“最终请求”分离。构建器本身应是值类型（避免隐式共享），且所有 setter 方法必须返回新实例（支持链式），而不是修改原实例。
-
RequestBuilder字段只存原始参数：method、url、body、headers（map[string][]string）、timeout、query（url.Values） - 每个 setter（如
WithHeader()）都基于当前字段 shallow copy 后修改，再返回新RequestBuilder - 最终
Build()方法才调用http.NewRequest，并注入所有累积配置；此时body需用io.NopCloser或bytes.NewReader封装，确保每次Build()都产生独立io.ReadCloser - 如果需要支持 context（如超时/取消），应在
Build()接收context.Context参数，而非在构建器里存 context（context 不可复制）
Build() 里最容易被忽略的三个细节
很多手写的构建器在这里出错，导致请求发不出、header 丢失、或 panic：
-
url.Parse失败时必须显式检查错误，不能直接panic或忽略——建议在Build()中返回(*http.Request, error) -
req.Header是http.Header类型（即map[string][]string），但标准库要求 key 必须是规范化的（如"Content-Type"而非"content-type"）。手动赋值时要用req.Header.Set()或req.Header.Add()，别直接写req.Header["X-Trace-ID"] = []string{"abc"}（可能被忽略） - 如果设置了
query参数，需手动拼接到 URL：先u := *baseURL，再u.RawQuery = query.Encode()，最后传给http.NewRequest；漏掉这步，query 参数就丢了
要不要封装 http.Client 的行为（如重试、中间件）
构建器只负责组装 *http.Request，不该耦合发送逻辑。重试、日志、指标等应交给独立的 HTTPClient 包装器（比如用 middleware 模式包装 http.Client.Do）。否则会出现两个问题：
- 构建器职责爆炸：既要管请求结构，又要管发送策略，违反单一职责
- 难以测试：你没法 mock 一个混着构建+发送的类型；而纯构建器可直接断言字段值
- 性能隐患：如果构建器内部缓存了
*http.Client，却没处理 transport 复用或 timeout 继承，反而引发连接泄漏
真正要做的，是让构建器输出干净的 *http.Request，然后由外部决定用哪个 http.Client 发送——这才是 Go 的惯用法。
