直接用 net/http 写路由难以维护，因缺乏路径参数、中间件、动态配置及服务发现能力；应使用 gorilla/mux 构建可扩展路由骨架，并严格控制转发细节与配置热更新。
为什么直接用 net/http 写路由不够用
你写了个 http.HandleFunc，加了几个 if req.URL.Path == "/user" 就算路由？问题不在“能不能跑”，而在“能不能维护”。真实网关要处理鉴权、限流、重试、超时、Header 转发、后端服务发现——这些全靠 if/else 堆，两周后自己都不敢改。
核心矛盾是：HTTP 服务器 ≠ API 网关。前者只管连接和响应，后者得理解请求语义、干预转发链路、做策略决策。
-
net/http.ServeMux不支持路径参数（如/users/{id}），得自己正则解析 - 没有内置中间件机制，鉴权/日志/熔断逻辑会散落在每个 handler 里
- 无法动态加载路由规则，改个路径要重启服务
- 后端地址硬编码在代码里，没法对接 Consul/Etcd 做服务发现
用 gorilla/mux 搭基础路由骨架
gorilla/mux 是最轻量又够用的路由库，不侵入 HTTP 生命周期，只解决“把请求精准派给谁”这件事。它比 httprouter 更易调试，比 chi 更少抽象层，适合网关起步阶段。
关键不是怎么写路由，而是怎么组织路由结构：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
router.Host("api.example.com").Subrouter()隔离不同域名流量 - 用
r.Methods("GET", "POST")显式声明方法，避免OPTIONS漏放行 - 路径变量必须用
{id:[0-9]+}而非{id}，防止正则回溯炸 CPU - 所有路由最后接
.HandlerFunc(proxyHandler)，把转发逻辑收口到一个函数
示例：
router := mux.NewRouter()
api := router.PathPrefix("/v1").Subrouter()
api.HandleFunc("/users/{id:[0-9]+}", proxyHandler).Methods("GET")
api.HandleFunc("/users", proxyHandler).Methods("POST")
转发请求时必须手动控制的 4 个细节
网关不是 http.Redirect，是透传。Go 的 http.Transport 默认行为在代理场景下几乎全是坑。
- Host 头必须显式设置为后端地址，否则下游服务看到的是网关自己的 Host
- 要删掉
Connection、Keep-Alive、Proxy-Authenticate等 hop-by-hop header（RFC 7230 6.1） - Body 必须用
io.Copy流式转发，不能全读进内存，否则大文件上传直接 OOM - 超时必须分三段设：
Transport.DialContext（建连）、Transport.ResponseHeaderTimeout（读 header）、Client.Timeout（整个请求）
漏掉任何一项，都会出现“请求卡住”“502 Bad Gateway”“后端收不到 Body”这类典型故障。
配置热更新别碰 fsnotify，用 viper + watch 更稳
路由规则写死在代码里等于没做网关。但用 fsnotify 监听 YAML 文件变化，容易遇到文件锁、事件丢失、并发 reload 导致路由表错乱。
viper.WatchConfig() 底层已封装重试和串行化，配合 viper.OnConfigChange 回调即可安全替换路由树：
- 新配置校验失败时，保留旧
*mux.Router，不 panic 不中断流量 - 切换时用
atomic.StorePointer替换全局 router 指针，避免锁竞争 - 配置项必须含
timeout_ms、retry_times、upstream_url，不能只存路径映射
真正难的不是“怎么加载”，而是“加载失败时请求是否继续走旧规则”——这个边界必须在代码里写死，不能依赖运维手动切流。
