beego不是微服务网关，不提供超时熔断能力；http客户端调用必须显式设置超时，否则goroutine永久阻塞；熔断器应封装在服务客户端而非controller或路由层，且需按服务+接口粒度独立配置并手动上报指标。
Beego 不是微服务网关，它本身不提供超时熔断能力——所有相关逻辑必须手动注入到 Controller 或 Service 层，否则请求会卡死或级联失败。
Beego 中 HTTP 客户端调用必须显式设置超时
Beego 的 http.Client 默认无超时，直接用 http.Get 或 http.Post 会导致 goroutine 永久阻塞。你得自己构造带超时的 client：
- 不要写
http.Get("http://user-svc/users/123")—— 这没有超时控制 - 应该用
http.DefaultClient替换为自定义 client：client := &http.Client{<br> Timeout: 3 * time.Second,<br>} - 如果用了 beego 内置的
beego.HttpGet等快捷方法，它们底层仍走http.DefaultClient，一样没超时，必须绕开 - 更稳妥的方式是封装一个统一的 service client，在初始化时注入 context 和 timeout，比如
NewUserServiceClient(ctx, timeout)
gobreaker 熔断器不能包装整个 Controller 方法
把 cb.Execute 直接套在 Get() 或 Post() 上，等于让每个 HTTP 请求都触发熔断器状态机判断，高并发下会成为性能瓶颈，且无法透传 request-scoped 的 context。
- 错误做法：
func (c *OrderController) Get() {<br> result, err := cb.Execute(func() (interface{}, error) {<br> // 整个 controller 逻辑<br> return c.fetchOrder(), nil<br> })<br>} - 正确做法：只包装明确的远程调用点，例如
userServiceClient.GetUser(ctx, id)，且确保该函数内部使用传入的ctx - 别在
Execute里启动新 goroutine 或做非 IO 操作，否则失败统计失真 - 若用
context.WithTimeout，必须在Execute外层设置，并透传进被包装函数，否则超时后熔断器仍会计为失败
Beego 路由层无法替代网关级熔断
有人试图在 beego.Router 或中间件里统一封装熔断逻辑，这是危险的抽象——它混淆了「业务路由」和「依赖治理」的边界。
- Beego 的中间件（如
InsertFilter）适合做鉴权、日志、跨域，不适合做熔断：它无法区分哪个请求调用了哪个下游服务，也无法按服务维度配置MaxRequests或Interval - 真正的熔断粒度是「服务+接口」，比如
payment-service/charge和user-service/get应该各自独立熔断器 - 如果你硬要在路由层加，结果就是所有请求共用一个熔断器，低频服务被高频服务拖垮，或反过来误熔断
- 真实生产环境应把熔断下沉到 SDK 层（如封装好的
UserClient），而不是框架路由层
最容易被忽略的一点：Beego 没有自动指标上报，gobreaker 的状态变化、失败原因、半开试探次数全靠你自己打日志并暴露 Prometheus metrics，否则出了问题根本不知道是超时、连接拒绝，还是熔断器主动拒绝。
