beego.Router绑定Controller实例，走完整MVC生命周期并支持TplName等字段；beego.Get/Post注册闭包函数，绕过MVC无上下文字段，仅可用裸ctx取参，且函数式路由优先级更高会覆盖Router。
beego.Router 和 beego.Get/Post 的本质区别在哪
根本不是“写法不同”，而是注册对象和执行链路完全不同。前者绑定 &Controller{} 实例，请求进来会 new 一个 controller、走完整生命周期（Init→Prepare→Get→Finish），参数通过 this.Ctx.Input.Param(":id") 拿；后者直接注册闭包函数，绕过所有 MVC 上下文，this.TplName、this.Data 全不可用，只能靠裸 ctx.Input.Param(":id") 手动取参。
常见错误现象：beego.Router("/user/:id", &UserController{}) 和 beego.Get("/user/:id", func(ctx *context.Context){...}) 同时存在，后者会覆盖前者 —— 因为函数式路由优先级更高，且不共享 controller 字段。
- 需要模板渲染、Session、CSRF 或自动 JSON 输出？必须用
beego.Router+ Controller - 只是简单返回 JSON 或状态码，无状态轻接口？
beego.Get更轻量，但别指望this.ServeJSON() - 混用时务必检查注册顺序，函数式路由永远赢
正则参数怎么写才不会丢 ID 或匹配失败
:id:int 看似方便，但底层展开为 id([0-9]+)，遇到带连字符的 UUID 就失效。框架不会帮你做语义推断，所有正则都得显式写全。
典型错误：写 :oid:string 以为能匹配 abc-123，实际只匹配 [\w]+（不含 - 和 .）；写 /files/* 却忘了 :splat 拿到的路径不带开头的 /，导致拼接文件系统路径出错。
立即学习“go语言免费学习笔记（深入）”；
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 匹配 UUID 或含连字符 ID：
beego.Router("/order/:oid([a-z0-9-]+)", &OrderController{}) - 可选后缀段（如
/api/users/123或/api/users/123/json）：beego.Router("/api/users/:id?:format", &APIController{})，注意?:是必须前缀 - 通配剩余路径：
/download/.*→ 自动拆出:path和:ext；/files/*→ 只有:splat，值为"img/logo.png"（不含/files/） - 字面量点号必须转义：
/static/css/main\.css，否则.被当通配符
RESTful 路由第三个参数 "get:Get;post:Create" 的陷阱
这个字符串看着清晰，但三处隐性风险常被忽略：方法名大小写敏感（Get 不等于 get）、方法必须是导出（首字母大写）、且控制器里真得有对应签名的函数。少一个就 panic，而不是 405。
更麻烦的是，*:Index 不处理 OPTIONS 预检请求，前端发 CORS 请求直接卡住；多个 method 映射同一路径时（比如 get,put,delete 都指向 /api/item/:id），框架不会自动判 ctx.Request.Method，得在 Get 方法里手动加 if this.Ctx.Request.Method == "PUT" 分支 —— 这就违背了 RESTful 本意。
- 确保控制器方法名完全匹配字符串里的大小写，且是导出方法（
func (c *XController) Get()） - 需要
OPTIONS支持？必须单独注册：beego.Options("/api/*", func(ctx *context.Context){ ctx.Output.SetStatus(200) }) - 不想手动判 Method？改用单方法路由，或把逻辑提到
Prepare()统一处理 - 生产环境慎用
*，暴露未实现方法容易 panic
AutoRouter 为什么生产禁用
beego.AddAuto(&controller.MainController{}) 看着省事，但它在启动时扫描所有导出方法、按命名规则（Get/Post 开头）自动生成路由，路径固定为 /controllername/methodname，无法排除某个方法，也不能加中间件或正则约束。
性能上，它依赖反射遍历结构体方法，启动慢；语义上，/main/getusers 这种路径不符合 REST 规范，也难维护。最致命的是：一旦 controller 增加新方法，路由就自动多一条，可能暴露调试接口。
- 开发期快速验证逻辑可用，但上线前必须全部替换成显式
beego.Router - 路径不可控，比如
func (c *MainController) InitDB()也会被注册成/main/initdb - 无法绑定中间件，安全校验、日志、限流都得写进每个方法里
真正麻烦的从来不是“怎么写路由”，而是 controller 生命周期、参数提取时机、method 分发顺序这三者咬合是否严丝合缝。哪怕正则写对了，Prepare() 里没调 super.Prepare()，this.Ctx.Input.Param() 就是空的 —— 这类链路中断问题，比语法错误更难定位。
