http.transport 转发会丢请求头因默认清理 hop-by-hop 头（如 connection、authorization）；需手动复制头并调 delhopheaders；body 只能读一次，须用 io.readall + bytes.newreader 重建并设 contentlength；reverseproxy 灵活性差，需自定义改写时应手动 roundtrip；响应转发须用 io.copy、清 content-length、透传 chunked、defer close；长连接需调 idleconntimeout 和 keepalive。
为什么直接用 http.Transport 转发会丢请求头？
Go 的 http.Transport 默认会清理掉一些“不安全”或“hop-by-hop”的请求头，比如 Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization、Te、Trailer、Upgrade。如果你没手动恢复，后端服务可能收不到原始的 Authorization 或 Cookie，甚至直接 400。
解决方法是显式复制所有原始头，并跳过 hop-by-hop 判定：
- 用
req.Header.Clone()复制头（Go 1.19+），或遍历req.Header手动赋值（旧版本） - 调用
delHopHeaders(req.Header)清理掉必须删的头（如Connection指定的字段） - 别依赖
http.DefaultTransport的默认行为，它不为你代理场景优化
如何正确处理 http.Request 的 Body 转发？
Body 是 io.ReadCloser，只能读一次。直接 http.DefaultTransport.RoundTrip(req) 前若已读过 Body（比如为了日志或鉴权），转发时会得到空体 —— 后端收不到 POST 数据或 JSON。
常见错误现象：400 Bad Request、后端解析出空 JSON、req.Body == nil 却没报错。
立即学习“go语言免费学习笔记（深入）”；
- 需要在读取 Body 前先用
io.ReadAll(req.Body)拿到原始字节，再用bytes.NewReader()重建req.Body - 记得设
req.ContentLength，否则 Go 会自动设为 -1，导致某些后端拒绝接收 - 如果 Body 很大（>几 MB），避免全量内存缓存；可改用
io.TeeReader+ 临时文件，但得自己管理生命周期
http.ReverseProxy 能不能直接用？什么情况下要绕开它？
标准库的 httputil.NewSingleHostReverseProxy 确实能跑通简单代理，但它对中间修改控制弱：你没法在转发前动态改 Host、加 Header、重写 URL 路径，也没法细粒度拦截响应体。
使用场景举例：需把 /api/v1/ 重写为 /v1/；需根据请求头决定上游地址；需注入 X-Forwarded-For 但屏蔽原始 IP。
- 想自定义逻辑，就别封装在
ReverseProxy里，直接用http.Server+ 手动RoundTrip - 若只做透明转发且无改写需求，
ReverseProxy更省心，但记得设置Director函数修正req.URL.Host和req.Host - 它默认不传递
X-Real-IP，也不清理Upgrade头，WebSocket 代理容易卡在 101 响应后断连
响应体转发时为啥会卡住或超时？
典型表现：浏览器转圈、curl 卡住、日志里看不到 200 OK，但代理进程 CPU 不高 —— 很可能是响应体没被完整读完或没关流。
根本原因：Go 的 http.ResponseWriter 是写即发，但底层 TCP 连接依赖双方都按 HTTP 协议收发完毕。漏读响应 Body、没设 Content-Length、或用了 Transfer-Encoding: chunked 却没透传，都会让客户端等不到结束信号。
- 务必用
io.Copy(w, resp.Body)而不是w.Write(...)，后者不处理流式响应 - 转发前删掉
resp.Header中的Content-Length（除非你确定长度不变），让 Go 自动计算 - 遇到
chunked编码，不要试图解 chunk，原样透传；io.Copy会自动处理 - 别忘了
defer resp.Body.Close()，否则连接池耗尽，后续请求全挂
最麻烦的其实是长连接和流式接口（如 SSE、gRPC-Web）——它们依赖底层连接不关闭，而 Go 默认的 http.Transport 可能因 idle timeout 主动断开。这时候得调 IdleConnTimeout 和 KeepAlive，不是加几行代码就能搞定的事。
