Beego 框架不提供自动熔断与请求屏蔽能力，也无内置速率限制、IP黑名单、失败计数器或电路熔断器；其“自动防护”仅限拒绝非标HTTP方法、静态资源预匹配及手动abort钩子，上传体大小须开发者手动用http.MaxBytesReader限制。
beego 框架本身**不提供自动熔断与请求屏蔽能力**，也没有内置的速率限制、IP黑名单、失败计数器或电路熔断器。所谓“自动防护”仅限于基础层：比如对非标准 HTTP 方法（如 TRACE、CONNECT）的拒绝、静态资源路径的预匹配跳过、以及 BeforeRouter 阶段可手动 abort 的钩子——但这些都需开发者显式编码实现。
Beego 里没有 http.MaxBytesReader 自动封装，上传体大小必须手动加限
框架不会拦截超大请求体，r.Body 默认可被任意读取。如果你没在 BeforeRouter 或 handler 开头写：r.Body = http.MaxBytesReader(w, r.Body, 20，攻击者发一个 500MB 的 POST 就可能直接 OOM。
- 所有上传接口（尤其是
ParseMultipartForm）必须前置套http.MaxBytesReader，maxMemory参数只是内存缓存上限，不是总大小限制 - 使用
beego.MaxMemory配置只影响ParseMultipartForm的内存阈值，不防恶意大文件 - 推荐全局用
http.MaxBytesHandler包裹整个beego.BeeApp.Handlers，比每个路由手写更可靠
Beego 的过滤器链无法替代熔断器，状态无法跨请求共享
像 BeforeRouter、AfterStatic 这类过滤器是无状态的：每次请求新建一个 *context.Context，你无法在其中累积失败次数、统计 IP 请求频次或维持熔断开关。想做 IP 限流或接口级熔断，必须外接：
- 用
sync.Map+ 时间窗口做简易内存限流（注意 GC 和 goroutine 泄漏） - 集成
github.com/sony/gobreaker，但必须在业务调用下游前（如 DB 查询、HTTP client.Do）包裹cb.Execute()，不能包整个 handler - 把熔断状态存在 Redis，用 Lua 做原子计数，否则并发下计数不准
静态文件请求绕过所有常规过滤器，权限校验容易失效
请求 /static/private/report.pdf 不会触发 BeforeRouter 或 BeforeExec，哪怕你写了 session 校验或 JWT 解析——它只走 BeforeStatic 这一条钩子。很多团队在这里翻车：
- 误把鉴权逻辑放在
BeforeRouter，结果私有静态资源完全裸奔 -
BeforeStatic中没调ctx.Abort()或没正确写http.Error，导致 403 不返回、客户端拿到空响应 - session 在
BeforeStatic中未初始化（因为 beego 默认 session 初始化在AfterStatic后），直接调sess.Get("user")返回 nil
MaxBytesReader + gobreaker）、以及静态资源专用过滤点（BeforeStatic）。Beego 的角色是路由分发和 MVC 组织，不是安全网关。别指望它自动扛住慢速攻击、CC 或大文件轰炸——那些都得你亲手焊上去。 
