gin嵌套分组必须用上层routergroup实例调用.group()，而非直接用engine创建；否则前缀、中间件全失效，如admin := v1.group("/admin")才生成/api/v1/admin，而r.group("/admin")仅为平行分组。
嵌套分组必须用上层 Group 实例调用
嵌套不是靠路径拼接，而是靠 RouterGroup 实例的层级关系。比如 r.Group("/api") 返回一个 *gin.RouterGroup，它的子分组必须由它来调用 .Group()，不能直接用 r.Group("/api/v1")——否则就脱离了父级上下文，中间件、前缀继承全失效。
常见错误现象：v1 := r.Group("/api/v1"); admin := r.Group("/admin") 看似嵌套，实则平行；/api/v1/admin 不会自动存在，必须显式写成 admin := v1.Group("/admin")。
-
v1 := r.Group("/api/v1")是父分组 -
admin := v1.Group("/admin")才是正确嵌套（路径最终为/api/v1/admin） -
logs := admin.Group("/logs")会生成/api/v1/admin/logs
嵌套时中间件顺序按洋葱模型逐层包裹
每层分组的 .Use() 都会叠加在当前层级的 handler 外围，和全局中间件一起构成完整执行链。父组中间件一定比子组先执行，子组中间件又一定比其内部路由 handler 先执行。
典型陷阱：在 v1.Group("/api/v1") 里加了 Auth()，又在 v1.Group("/admin") 里加了 RBAC()，那么请求 /api/v1/admin/logs 的执行顺序是：全局中间件 → v1.Auth() → admin.RBAC() → logs handler。
- 不支持“覆盖”，只支持“叠加”
- 若想某层跳过父组中间件，只能拆成独立分组（但会丢失前缀）
- 调试时可用
c.Keys或日志打点验证中间件是否真正进入
路由文件抽离时参数类型必须是 *gin.RouterGroup
把嵌套逻辑拆到单独文件，函数签名若写成 func InitRoutes(r *gin.Engine)，所有路由都会注册到根引擎，/api/v1/admin 变成 /admin——因为 r.Group() 调用被忽略，.GET() 默认落到 r 上。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
正确做法是让外部传入分组实例，保持作用域绑定：
func InitAdminRoutes(rg *gin.RouterGroup) {
rg.GET("/dashboard", dashboardHandler)
rg.POST("/settings", updateSettingsHandler)
}
// main.go 中：
v1 := r.Group("/api/v1")
admin := v1.Group("/admin", AuthMiddleware())
InitAdminRoutes(admin)
- 传
*gin.Engine→ 前缀和中间件全部丢失 - 传
*gin.RouterGroup→ 路径拼接、中间件链、作用域全保留 - 嵌套越深，这个参数类型越不能错，否则 debug 成本指数上升
嵌套分组里不要省略花括号 {}
哪怕只有一条路由，也必须用 {} 包裹。这不是风格问题，是 Go 作用域和 Gin 内部实现决定的：没有 {}，.GET() 等方法调用不会绑定到分组变量，而是静默注册到根引擎。
错误写法：admin := v1.Group("/admin"); admin.GET("/list", listHandler) → 实际注册的是 /list，不是 /api/v1/admin/list。
- 正确写法必须带块作用域：
admin := v1.Group("/admin"); { admin.GET("/list", listHandler) } - Go 编译器不会报错，但路由行为完全不符合预期
- IDE 无法提示这类逻辑错误，只能靠测试或打印
r.Routes()检查注册结果
嵌套本身不难，难的是每一层的实例传递、作用域绑定和中间件堆叠顺序——漏掉任何一个，都可能让鉴权绕过、日志缺失或 404 难以定位。
