httputil.NewSingleHostReverseProxy 是轻量反向代理方案，需用 url.Parse 解析 URL 避免 panic；Director 中须重写 Scheme、Host、Path 并补全 X-Forwarded-For；路径前缀路由需 path.Clean + TrimPrefix；请求头应白名单透传；context canceled 错误源于客户端断连或超时，需日志捕获与链路监控。
用 net/http/httputil.NewSingleHostReverseProxy 快速启动反向代理
Go 自带的 httputil.NewSingleHostReverseProxy 是最轻量、最直接的 API 网关起点。它不依赖第三方库，5 行代码就能把请求转发到后端服务。
常见错误是直接传入字符串 URL 而没解析成 *url.URL，导致 panic：panic: url can't be nil。必须用 url.Parse 先转一次。
- 使用场景：开发期快速验证路由、协议转换（HTTP→HTTPS）、加一层日志或基础鉴权
-
Director函数必须显式重写req.URL.Host和req.URL.Scheme，否则默认保留原始 Host，后端可能收不到正确 Host 头 - 注意：该代理默认不转发
X-Forwarded-*头，需手动补全，否则下游服务拿不到真实客户端 IP
u, _ := url.Parse("http://localhost:8081")
proxy := httputil.NewSingleHostReverseProxy(u)
proxy.Director = func(req *http.Request) {
req.URL.Scheme = u.Scheme
req.URL.Host = u.Host
req.Header.Set("X-Forwarded-For", req.RemoteAddr)
}
为什么 Director 里要改 req.URL.Path 才能做路径前缀路由
默认 Director 不修改路径，所有请求原样透传。想实现类似 /api/v1/users → http://svc/users 这种前缀剥离，必须手动截断。
容易踩的坑是用 strings.TrimPrefix 粗暴处理，但没考虑路径结尾斜杠、重复斜杠或编码字符，导致 404 或路径错乱。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：用
path.Clean规范路径，再用strings.TrimPrefix剥离前缀，最后确保开头有/ - 如果网关监听
/api/v1/，而目标服务期望根路径/，那req.URL.Path就得从/api/v1/users变成/users - 性能影响极小，但每次请求都走一遍字符串操作，高并发下建议提前编译正则或缓存路径规则（不过简单前缀场景没必要）
proxy.Director = func(req *http.Request) {
req.URL.Scheme = u.Scheme
req.URL.Host = u.Host
req.URL.Path = path.Clean(strings.TrimPrefix(req.URL.Path, "/api/v1"))
if req.URL.Path == "" {
req.URL.Path = "/"
}
}
如何安全地透传请求头而不暴露内部信息
默认 ReverseProxy 会过滤掉部分敏感头（如 Connection、Upgrade），但也会漏掉你真正想传的头（比如 Authorization、X-Request-ID），同时又可能把内部头（如 X-Real-IP、Server）传给下游。
典型错误是直接 req.Header.Clone() 后全量转发，结果把调试用的 X-Debug-Token 泄露出去，或让后端误判客户端协议版本。
- 推荐做法：白名单机制 —— 显式指定允许透传的头名，其余一律删掉
-
hopHeaders列表（如Connection、Keep-Alive）会被自动删除，不用额外处理 - 若需传递自定义认证头（如
X-API-Key），必须在ModifyResponse或Director中手动设置，不能靠默认行为
遇到 http: proxy error: context canceled 怎么定位
这个错误不是网关代码写错了，而是上游客户端（比如 curl、前端）主动断开连接，或者超时了。但新手常误以为是代理本身崩了。
根本原因是 Go 的 ReverseProxy 使用了上下文传播，一旦客户端关闭连接，RoundTrip 就会收到 context.Canceled 并返回该错误。它本身不致命，但高频出现说明链路不稳定。
- 检查点一：客户端是否设置了过短的 timeout（比如 fetch 的
signal或 axios 的timeout） - 检查点二：后端响应太慢，触发了网关层的
http.Server.ReadTimeout或WriteTimeout - 检查点三：Nginx / ALB 等前置 LB 有更激进的空闲超时（如 60s），比 Go 服务设的还短
- 不要 suppress 这个错误日志 —— 它是链路健康的重要信号，应记录并监控频次
复杂点在于，这个错误不会中断整个服务，但会影响可观测性。如果你没在 proxy.ErrorHandler 里专门捕获并打标，它就混在普通日志里，很难和真正的后端崩溃区分开。
