httputil.NewSingleHostReverseProxy需手动配置Director重写URL.Host/Scheme/Path、透传X-Forwarded-For、共享Transport连接池，并配合路由分发才能安全可用，否则易致404、502、IP丢失及连接耗尽。
用 httputil.NewSingleHostReverseProxy 搭出第一个可跑的代理
Go 语言没有开箱即用的 API 网关，但标准库 net/http + httputil 足够快速启动一个能转发请求的网关雏形。最简路径就是调用 httputil.NewSingleHostReverseProxy，它本质是一个实现了 http.Handler 的反向代理结构体。
常见错误是直接传入原始请求路径，导致后端收到带前缀（如 /api/users）的 URL 却没做路径剥离，结果 404。必须手动改写 Director 函数：
-
Director里要重写r.URL.Host和r.URL.Scheme，否则 Host 头和协议可能错乱 - 若需去掉路由前缀（比如把
/user/123转为/123发给用户服务），得用strings.TrimPrefix(r.URL.Path, "/user")再赋值给r.URL.Path - 记得显式设置
r.Header.Set("X-Forwarded-For", r.RemoteAddr)，否则下游服务拿不到真实客户端 IP
为什么不能只靠 NewSingleHostReverseProxy？路由多目标怎么处理
单主机代理只适用于固定后端，而真实网关必须根据路径、Host 或 Header 动态选服务。硬编码多个 ReverseProxy 实例再用 http.ServeMux 分发，会导致每个代理都维护独立连接池，浪费资源且无法统一控制超时。
更合理的做法是：用一个 http.ServeMux 或 gorilla/mux 做路由分发，每条路由绑定自己的 Director 和 ReverseProxy 实例（注意复用 Transport）。关键点：
立即学习“go语言免费学习笔记（深入）”；
- 所有
ReverseProxy应共享同一个自定义http.Transport，否则连接池不生效 - 路由匹配优先级很重要：
/api/v1/users必须比/api更早注册，否则后者会吞掉前者 - 避免在
Director中做耗时操作（如查数据库），否则阻塞整个 goroutine
http.Transport 连接池配置不当会拖垮整个网关
默认 http.DefaultTransport 的连接池极小（MaxIdleConns=100，MaxIdleConnsPerHost=2），高并发下容易卡住或新建大量 TCP 连接，表现就是后端响应延迟飙升、TIME_WAIT 暴增。
生产环境必须覆盖这些参数：
-
MaxIdleConns设为 1000+，避免连接频繁创建销毁 -
MaxIdleConnsPerHost至少设为 100，否则单个后端实例连接数被掐死 -
IdleConnTimeout控制空闲连接存活时间，90s 是较稳妥值 -
TLSHandshakeTimeout和ResponseHeaderTimeout必须设，防止慢握手或慢响应拖住整个连接池
漏配 ResponseHeaderTimeout 是高频坑：后端卡在写响应头时，连接就一直占着不放，新请求排队等不到空闲连接。
别急着加 JWT 或限流中间件——先稳住转发链路
新手常犯的错误是上来就堆认证、日志、熔断，结果一压测就发现 60% 的延迟来自中间件本身，而非代理转发。真正的瓶颈往往在底层链路：DNS 解析慢、TLS 握手耗时、后端响应头未及时写出。
建议分阶段验证：
- 第一步：关闭所有中间件，只跑纯代理，用
ab或hey测通吐量，确认Transport配置生效 - 第二步：加
log中间件，但日志必须异步写（例如发到 channel 由单独 goroutine 刷盘），否则阻塞主流程 - 第三步：再引入
rate或golang.org/x/time/rate限流，注意桶容量和速率要按后端实际承载力设，不是拍脑袋
转发链路没压稳之前，任何上层逻辑都是空中楼阁。很多线上故障不是代码写错，而是连接池或超时配置没对齐后端真实水位。
