必须立即配置proxy.director和errorhandler：director需重写req.url.path（用strings.trimprefix严格匹配前缀）和req.host（影响http host头），errorhandler不可省略以防panic崩溃。
别从“环境搭建”开始——高性能网关的瓶颈从来不在 go mod init 或 GOPATH 配置上，而在 httputil.NewSingleHostReverseProxy 的 Director 和 ErrorHandler 是否写对。
go mod init 之后第一行代码该写什么
不是写路由、不是加中间件、更不是配 TLS；而是立刻构造一个能跑通的反向代理实例。这一步卡住，后面所有“高性能”都是空谈。
- 用
net/url.Parse("http://backend:8080")解析目标地址，传给httputil.NewSingleHostReverseProxy - 必须立即赋值
proxy.Director，哪怕只做最简路径改写：req.URL.Path = strings.TrimPrefix(req.URL.Path, "/api") - 跳过
proxy.ErrorHandler设置？Panic是默认行为，线上会直接 kill 整个 HTTP server - 不要用
gin或chi封装代理逻辑——它们会遮蔽Director执行时机，导致req.Host没被重写却以为转发成功
为什么 httputil.NewSingleHostReverseProxy 的 req.Host 必须显式赋值
HTTP 协议里 Host 头决定后端服务如何路由。Kubernetes Service、Nginx upstream、甚至 Spring Cloud Gateway 都依赖它做匹配。不设，就发原始 Host（比如 gateway.example.com），后端直接 404 或 401。
在SEO发布前，从路由清单生成XML网站地图和robots.txt
下载
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
-
req.Host和req.URL.Host是两个字段：前者控制 HTTP 请求头，后者控制连接目标地址 - 常见错误是只改了
req.URL.Host，漏掉req.Host = "backend-service:8080" - 若后端是 gRPC over HTTP/2，
req.Host还影响 ALPN 协商，不一致会导致http2: server sent GOAWAY and closed the connection
strings.TrimPrefix 的三个致命细节
看似简单的路径截断，90% 的 404 都出在这里。它不是字符串替换，而是前缀匹配，且区分大小写、严格比对斜杠。
- 第二个参数多一个
/（如"/api/v1/"）或少一个（"api/v1"），整个截断失效 - 路由注册路径是
/api/v1/users，但TrimPrefix写成"/API/v1"？大小写不一致 → 不匹配 → 后端收到完整路径 → 404 - 建议把 prefix 提取为常量或配置项，例如
const apiPrefix = "/api/v1"，所有地方统一引用，避免硬编码散落
代理层超时和连接池不配等于没配
默认 Transport 对每个后端只开 2 个连接、60 秒超时，在压测下很快打满。这不是性能“优化”，而是基础可用性门槛。
- 必须重写
proxy.Transport，设置MaxIdleConns≥ 1000，IdleConnTimeout≥ 90s -
Timeout要设在http.Server层（读/写/空闲超时），不能只靠 Transport 的ResponseHeaderTimeout - 别信 “Go 自带连接复用很高效” —— 默认值是为单机 CLI 工具设计的，不是为每秒千请求的网关
真正难的不是写多少行代码，而是每次改 Director 都得验证三件事：路径是否被正确剥离、Host 头是否抵达后端、错误是否真被 ErrorHandler 捕获并返回 HTTP 状态码。漏掉任何一条，线上就静默失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
