最可靠的方式是用 req.Header.Set 设置请求头，需在 NewRequest 后手动调用；Content-Type 必须显式设置（如 JSON 请求设为 application/json），Host 默认自动填充，Header 非线程安全且不可复用。
直接用 req.Header.Set 添加请求头最可靠
Go 的 net/http.NewRequest 创建的请求对象本身不接受头信息作为参数，必须在返回的 *http.Request 上手动设置。调用 req.Header.Set 是标准做法，它会覆盖同名已有头；若需追加（比如多个 Cookie），改用 req.Header.Add。
常见错误是：在 NewRequest 后忘记调用 req.Header.Set，或误以为传入的 body 参数能携带头信息 —— 实际上不能。
-
req.Header.Set("User-Agent", "my-app/1.0")—— 覆盖式设单值头 -
req.Header.Add("Cookie", "session=abc")—— 追加式，允许多个同名头 - 设置前确保
req非 nil（NewRequest可能返回 error，需检查）
注意 Content-Type 和 Host 的自动行为
如果你用 http.NewRequest("POST", url, body) 且 body 是 *bytes.Reader 或 strings.Reader 等已知长度类型，net/http 会自动设置 Content-Length；但不会自动设 Content-Type —— 必须手动加，否则后端可能解析失败。
Host 头比较特殊：默认从 URL 解析并自动填充，但若你显式调用 req.Header.Set("Host", ...)，会覆盖自动值。这在反向代理或测试 mock 场景中有时需要，但多数情况别动它。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- JSON 请求务必加：
req.Header.Set("Content-Type", "application/json; charset=utf-8") - 表单提交用：
req.Header.Set("Content-Type", "application/x-www-form-urlencoded") - 修改
Host前确认客户端和服务端都支持该 Host 值，否则可能被中间件拦截
避免在重用 *http.Request 时头信息污染
*http.Request 不是线程安全的，且 Go 的 HTTP client 会复用底层连接，但不会复用 req 对象本身。不过，开发者有时会缓存 req 并多次调用 client.Do(req) —— 这是危险操作：头信息（尤其是 Authorization、Cookie）会残留，导致后续请求携带过期或错位的头。
- 每次请求都应新建
http.NewRequest，不要复用req实例 - 如果必须复用结构逻辑，把头设置封装进函数，每次传入新
req：func setupAuth(req *http.Request, token string) { req.Header.Set("Authorization", "Bearer "+token) } - 调试时可用
fmt.Printf("%+v", req.Header)快速查看当前头内容
自定义头名大小写不影响发送，但 Go 内部会规范化
HTTP 协议头名不区分大小写，Go 的 http.Header 底层用 map[string][]string 存储，key 是规范化的首字母大写形式（如 "User-Agent"）。你用 req.Header.Set("user-agent", "...") 也能工作，但 Go 会把它转成 "User-Agent" 再存。
这点对调试和日志友好，但要注意：用 req.Header.Get("USER-AGENT") 会返回空 —— 因为 Get 也走规范化匹配，不是字符串精确比对。
- 统一用标准驼峰写法（
User-Agent、X-Request-ID）减少混淆 - 自定义头建议以
X-开头（虽然 HTTP/2 已不强制，但兼容性更稳） - 若服务端严格校验头名原始大小写（极少见），Go 不支持，得换用底层
net.Conn自组 HTTP 报文
NewRequest，再 req.Header.Set。最容易漏的是 Content-Type，尤其 POST JSON 时没设，后端收不到 body 是最常踩的坑。 
