Gin的Engine不是单例，但应全局复用；多次new会导致路由丢失、中间件重复；gin.Default()每次新建但预装中间件；路由组织受IRouter/IRoutes接口约束；c.Next()实现洋葱模型；Radix Tree要求路径设计避免冲突与过度通配。
为什么Gin的Engine不是单例，但又不建议反复new
因为Engine实例本身携带了路由树、中间件链、配置项和全局状态（如gin.Recovery()和gin.Logger()是否启用），直接多次new gin.Engine()会导致路由注册丢失、中间件重复挂载、日志/panic恢复行为错乱。但gin.Default()也不是单例——它每次调用都新建一个Engine，只是默认预装了常用中间件。
实际项目中应只初始化一次r := gin.Default()或r := gin.New()，然后在整个生命周期内复用该实例。常见错误是：在函数内部反复调用gin.Default()并试图注册路由，结果只有最后一次生效。
-
gin.Default()=gin.New()+r.Use(gin.Logger(), gin.Recovery()) - 测试时可安全多次调用
gin.New()，因每个测试用例需隔离状态 - 生产环境若需多实例（如不同监听端口服务），应明确区分
r1和r2，而非复用同一变量
IRouter和IRoutes接口如何影响你写路由的方式
IRouter定义了Group()、Use()等分组与中间件方法；IRoutes则专注HTTP动词绑定，如GET()、POST()。它们不是让你去实现，而是决定了你“能怎么组织代码”。
比如r.Group("/api/v1").Use(authMiddleware)返回的是*RouterGroup，它同时实现了IRouter和IRoutes，所以既能继续Use()，也能直接GET("/users", handler)。但如果你写r.GET()，返回值类型是IRoutes，不能再链式调用Use()——这是编译期就限制死的。
立即学习“go语言免费学习笔记（深入）”；
- 想给某组路由加中间件？必须用
Group()开头，不能从GET()开始链式追加 -
RouterGroup嵌套合法：v1.Group("/admin").Group("/users")，最终路径是/api/v1/admin/users - 别把
IRouter当成抽象类去继承——Gin不鼓励自定义路由实现，Radix Tree逻辑已深度耦合在tree.go里
HandlerFunc链表与c.Next()背后的执行模型
Gin中间件本质是func(*gin.Context)组成的链表，c.Next()不是“调用下一个”，而是“让当前中间件暂停，交出控制权，等后续中间件全部跑完再回来继续执行剩余代码”。这就是洋葱模型的核心。
典型陷阱：在中间件里忘了调用c.Next()，整个请求链就卡住，下游路由永远不会执行；或者误在c.Next()后还写了业务逻辑，却没意识到那部分是在所有下游中间件和handler执行完才运行的。
- 鉴权失败时用
c.Abort()终止链，避免后续handler被调用 - 想在handler之后做清理（如记录耗时），必须写在
c.Next()之后 -
c.Set("key", value)和c.Get("key")是跨中间件传参的唯一安全方式，不要用闭包捕获局部变量
Radix Tree路由树对路径设计的实际约束
基数树要求路径片段尽量静态、避免过度通配。比如/user/:id/order/:oid可以高效匹配，但/user/*/order/*会退化为线性查找，/user/:id/:action若:action取值过多（如50+个固定字符串），不如拆成多个静态路由/user/:id/orders、/user/:id/profile。
更隐蔽的问题是冲突：Gin不允许/user/:id和/user/new共存于同一层级，因为new会被:id提前匹配。解决方式是把/user/new放在/user/:id之前注册，或改用/user/create这类无歧义路径。
- 参数路径
:id和通配路径*filepath不能混用在同一节点下 - 子路由
group.POST("/upload", ...)比r.POST("/v1/upload", ...)更利于树结构压缩 - 调试路由匹配问题，可用
r.PrintRoutes()输出当前树结构，观察节点优先级和priority值
Group()要早于GET()、c.Next()不是函数调用而是控制权移交、以及/user/new必须注册在/user/:id前面——这些细节不会报错，但会让问题延迟暴露到上线后。 
