beego.router 是底层路由注册方式，支持显式方法映射（如“get:fetch”）和类型约束；beego.get/post 是语法糖，仅绑定默认方法且不支持 restful 多方法或正则约束。
beego.Router 与 beego.Get/Post 的本质区别
两者都注册路由，但底层行为不同：beego.Get 和 beego.Post 是语法糖，内部调用 beego.Router 并自动绑定 HTTP 方法到控制器的 Get() 或 Post() 方法；而 beego.Router 更底层，允许你显式指定方法映射关系，比如 "get:Retrieve;put:Update"。
常见错误现象：混用时漏写第三个参数，导致 beego.Router("/user/:id", &UserController{}) 实际只响应 GET（因为默认 fallback 到 *:Get），PUT/DELETE 请求直接 405。
- 若控制器方法名不遵循 Beego 默认命名（如叫
Fetch()而非Get()），必须用beego.Router("/user/:id", &UserController{}, "get:Fetch") -
beego.Get等快捷函数不支持 RESTful 多方法分发，也不支持正则约束，仅适合最简场景 - 所有方式最终都注册进同一个 radix tree（基数树）结构，性能无差异，差异只在语义和灵活性
路径参数类型约束怎么写才生效
Beego 支持三种参数声明语法，但只有带冒号前缀的 :name:type 形式会被路由引擎识别为类型约束，:id:int 会自动编译为正则 ([0-9]+)，匹配失败则跳过该路由规则，不会 fallback 到其他路由。
容易踩的坑：beego.Router("/user/:id:int", &UserController{}) 中，如果请求是 /user/abc，Beego 不会报错或继续匹配下一个路由，而是直接返回 404 —— 因为类型校验发生在路由匹配阶段，不是 Controller 入口后校验。
-
:id:string对应正则([\w]+)，不匹配中文、短横线、下划线以外的字符 - 自定义正则必须用
@符号，如/download/*.*@(\.pdf|\.zip)，注意@后是纯正则表达式，不加括号包裹 -
this.Ctx.Input.Param(":id")只在匹配成功后有值；若想兼容可选参数，得用:splat或:path，但它们不参与类型校验
为什么 beego.AddAuto 没生效
beego.AddAuto 不是“自动发现”，而是“按约定反射注册”：它要求控制器方法必须是 public（首字母大写），且方法签名符合 func(*context.Context)，同时要确保控制器 struct 已被 Go 编译器加载（即该文件被 import 或在 main 包中引用过）。
常见错误现象：控制器放在 controllers/ 下但没被任何地方 import，或者方法名为 getUser()（小写），AddAuto 扫描时直接跳过，毫无日志提示。
- 使用
beego.AddAutoPrefix("/api", &UserController{})时，前缀只加在自动生成的路径前，不影响方法名映射逻辑 - 自动路由默认将
UserController.Get映射为GET /user（小写复数），这个转换不可配置；若需精确控制，应放弃AddAuto，改用Router - Beego 不扫描嵌套包下的控制器，
controllers/admin/UserController必须显式 import 后再传入AddAuto
反向代理场景下 beego.Router 的致命盲区
Beego 的路由系统只负责“把请求分发给哪个 Controller 方法”，它不处理网络转发。很多开发者误以为 beego.Router("/api/user", &ProxyController{}) 就能当网关用，结果 Controller 里没写代理逻辑，请求就卡在空响应或 404。
真实代理必须手动实现：用标准库 httputil.NewSingleHostReverseProxy，且要处理 Body 重放、Header 透传、状态码透出等细节。否则会出现请求体丢失、Content-Length 错误、超时无响应等问题。
-
c.Ctx.Request.Body是单次读取流，proxy.ServeHTTP会 consume 它；若之前中间件（如日志、鉴权）已读过 Body，必须用ioutil.NopCloser(bytes.NewReader(buf))复位 - Beego 的
BeforeExec过滤器在路由匹配之后、Controller 执行之前运行，无法拦截未匹配路由；真正网关需要的是 BeforeRouter 阶段介入 - 高并发下，每个请求都新建
ReverseProxy实例会显著拖慢性能；应提前构建并复用http.Transport和ReverseProxy实例
Beego 路由的“智能”体现在匹配效率（radix tree）和语法便利性，但它的核心仍是 MVC 框架的请求分发器，不是网关或代理层。任何试图绕过其设计边界的功能扩展，都会在参数解析、错误传播、连接复用等环节暴露隐性成本。
