beego不能作为大流量网关使用，因其非反向代理、无连接池/健康检查/热加载，qps几百即cpu打满；beego.router()仅做路径分发，不自动转发请求，需手动实现代理逻辑（含header复制、body重放等），且高并发下路由匹配、controller实例化与反射调用易成性能瓶颈。
Beego 不能作为大流量网关层使用 —— 它不是反向代理，也没有连接池、健康检查、动态路由热加载等网关必需能力。硬上会卡在 QPS 几百就打满 CPU，且故障无法自动转移。
beego.Router() 只做路径分发，不转发请求
很多人写 beego.Router("/api/users", &controllers.ProxyController{}) 就以为完成了网关路由，结果请求进来直接 404 或返回空响应。这是因为 Router() 只负责把 URL 匹配到某个 Controller 实例，并不执行任何 HTTP 转发逻辑。
- 它本质是 MVC 框架的路由层，匹配后调用
Get()/Post()方法，后续全靠你手写 - 若 Controller 里没写代理代码（比如没调
httputil.NewSingleHostReverseProxy），那请求就“消失”了 - 所有转发逻辑必须自己实现：Header 复制、Body 重放、超时控制、错误透传 —— 这些 Beego 一概不提供封装
手动实现反向代理时 Body 会被 consume 一次
这是最常踩的坑：c.Ctx.Request.Body 是单次可读的 io.ReadCloser，proxy.ServeHTTP() 内部会把它读完，之后再想取原始 Body（比如做日志、鉴权校验）就拿不到内容了。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 必须在调用
proxy.ServeHTTP()前，先用io.Copy(ioutil.Discard, c.Ctx.Request.Body)清空，或用bytes.NewReader()+ioutil.NopCloser()重建 Body - 如果用了中间件（如 JWT 解析），要确保它在代理前执行，否则 Body 已不可读
- 别依赖
c.Ctx.Input.RequestBody—— 它底层也是从Body读的，一样只能读一次
高并发下 Beego 路由和 Controller 实例化成瓶颈
Beego 路由用基数树（Radix Tree）匹配，单次查找很快，但整条请求链路要经历：路由匹配 → 新建 Controller 实例 → 反射调用方法 → 执行中间件 → 手写代理逻辑。QPS 上千时，GC 和反射开销就会明显拖慢吞吐。
- 真实网关（如 Kong、OpenResty）基于 epoll + 零拷贝，单机轻松扛几万 QPS；Beego 是同步阻塞模型，每个请求占一个 goroutine，无连接复用
- Controller 每次请求都 new 一次，频繁分配对象，GC 压力大
- 没有内置连接池，每次代理都要新建 HTTP client，DNS 解析、TLS 握手全得自己管
真正需要大流量网关，应该用 OpenResty/Nginx 做前置，Beego 只负责管理后台服务配置、提供 Admin API 或内部聚合接口。哪怕非要用 Go 写网关，也该选 gRPC-Gateway、fabio 或自研基于 net/http.Server + fasthttp 的轻量代理，而不是在 Beego 上叠代理逻辑。
