beego 不能直接当微服务网关用，因其缺乏反向代理、健康检查、负载均衡和协议转换能力，仅适合内部轻量接口聚合，真实网关能力需外部组件或自研补足。
Beego 不能直接当微服务网关用 —— 它不是反向代理，也没有健康检查、负载均衡或协议转换能力。硬要拿它做网关，得自己补全代理逻辑，否则只是个带路由的空壳。
beego.Router() 只匹配路径，不转发请求
很多人写完 beego.Router("/api/users", &controllers.UserProxyController{}) 就以为流量自动打到后端服务了。实际只是把请求交给了 UserProxyController，后续怎么处理完全由你控制。框架不会帮你调 http.Client、不会复用连接、也不会重试失败节点。
- 常见错误现象：
Get()方法里没写任何代理代码，返回空白页或 404 - 使用场景：仅适合内部轻量聚合（比如前端只认一个域名，后端多个 HTTP 接口拼装后统一返回）
- 性能影响：每个请求都要实例化 Controller + 反射调用方法，QPS 上千时反射开销和 GC 压力明显
手动实现反向代理必须处理 Body 复位
标准库 httputil.NewSingleHostReverseProxy 是最简方案，但 c.Ctx.Request.Body 是单次读取流，proxy.ServeHTTP 会把它 consume 掉。若中间件、日志或鉴权逻辑依赖原始 Body，就会出错。
- 必须在调用
proxy.ServeHTTP前做两件事：io.Copy(ioutil.Discard, c.Ctx.Request.Body)清空已读内容，再用c.Ctx.Request.Body = ioutil.NopCloser(bytes.NewReader(buf))重建可重读 Body - 别直接传
c.Ctx.Request给 proxy —— 它可能含不可序列化的字段（如Context、cancel函数），会导致 panic - Header 要显式复制：
c.Ctx.Request.Header.Clone()后再传给 proxy，否则 Host、Authorization 等关键头可能丢失
真实网关能力得靠外部组件或自研补足
Beego 没有内置熔断、限流、JWT 全局校验、gRPC/HTTP 协议转换这些网关核心能力。想支持，只能自己集成：
- 限流：用
golang.org/x/time/rate在Prepare()中拦截，按 path 或 client IP 控制速率 - JWT 鉴权：解析
Authorization: Bearer xxx后验证签名并注入 context，不能只靠中间件“挂载”就完事 - 服务发现：Beego 不感知 Consul/Etcd，需自己定时拉取实例列表，并在 proxy 逻辑中做随机/轮询选择
- 健康检查：得额外起 goroutine 主动探测下游
/health，维护可用节点缓存，否则故障节点还在转发
真正上线前，最易被忽略的是请求上下文传递 —— trace-id、user-id 这类字段若没从原始 Header 提取并透传给后端，分布式链路追踪就断了；还有超时控制，http.Client 的 Timeout 和 KeepAlive 必须显式设，否则默认是 0（无限等待）。
