Gin中Group方法用于路由分组，自动添加路径前缀，需显式挂载中间件；嵌套分组支持多级前缀；权限控制须结合JWT中间件与角色校验，c.Next()和c.Abort()决定执行链；中间件按注册顺序叠加，不可依赖路径前缀实现越权防护。
Go Gin 框架中 Group 方法的正确用法
路由分组不是靠手动拼接路径字符串实现的，而是通过框架原生的 Group 方法创建子路由器。Gin 的 Group 返回一个 *gin.RouterGroup，它继承了 Engine 的大部分路由方法（如 GET、POST），但所有注册的路由会自动带上前缀。
常见错误是把分组当成“命名空间”来用，却忘了中间件必须显式挂载——Group 本身不带任何中间件，包括认证或日志。
- 分组路径以
/开头，但不要重复写根路径，比如r.Group("/api/v1")后再注册.GET("/user")，最终路径是/api/v1/user - 多个分组可嵌套：
v1 := r.Group("/api/v1"); admin := v1.Group("/admin")，这样admin.GET("/users")对应/api/v1/admin/users - 分组不隔离变量作用域，
group.Use()只影响该分组及其子分组，不影响其他分组
Gin 路由分组 + JWT 权限控制的典型组合方式
权限控制不能只靠路径前缀，必须结合中间件提取并校验 token。Gin 中最常用的是在分组上统一挂载 JWTAuth() 类中间件，再在 handler 内部做细粒度判断（如角色字段比对）。
注意：不要在中间件里直接 c.Abort() 后就认为权限已拦截完毕——如果后续 handler 仍执行了数据库操作，说明中间件没生效或被绕过。
立即学习“go语言免费学习笔记（深入）”；
- 使用
github.com/golang-jwt/jwt/v5解析 token，从中取role或permissions字段 - 权限中间件应写成函数返回
gin.HandlerFunc，便于传参（如允许的角色列表）：func RoleRequired(roles ...string) gin.HandlerFunc { return func(c *gin.Context) { role, _ := c.Get("role") if !contains(roles, role.(string)) { c.JSON(403, gin.H{"error": "forbidden"}) c.Abort() return } c.Next() } } - 绑定到分组：
admin := r.Group("/admin").Use(JWTAuth(), RoleRequired("admin", "super"))
自定义路由分组时中间件执行顺序的关键细节
Gin 中间件按注册顺序执行，且 Group.Use() 和 Engine.Use() 是叠加关系，不是覆盖。如果全局注册了日志中间件，又在某个分组里注册了鉴权中间件，请求进入时先走全局日志，再进分组鉴权，最后才到 handler。
容易踩的坑是误以为分组中间件会“替代”全局中间件，结果导致未授权请求仍被记录日志，或鉴权前就触发了耗时操作（如 DB 连接）。
- 敏感操作类分组（如
/admin）建议只挂载必要中间件，避免继承不必要的全局中间件 - 若需排除某分组的全局中间件，只能拆出独立
gin.Engine实例，或在全局中间件中主动跳过特定路径前缀 -
c.Next()必须调用，否则后续中间件和 handler 不会执行；c.Abort()则终止后续链，但不会自动返回响应
用 Gorilla Mux 实现分组与权限的替代方案
如果你不用 Gin，Gorilla Mux 是另一个主流选择。它没有原生 Group 方法，但可通过 Subrouter 模拟等效行为，配合 StrictSlash 和 Headers 匹配做更细粒度控制。
它的优势在于路由匹配规则更灵活（支持正则、host、method），但缺点是权限逻辑得自己组织，没有 Gin 那样简洁的链式调用。
- 创建子路由：
admin := r.PathPrefix("/admin").Subrouter()，之后所有admin.HandleFunc(...)都自动带前缀 - 权限可封装为
http.Handler，用admin.Use(...)（需自行实现Use扩展）或包装 handler：admin.HandleFunc("/users", AuthMiddleware(AdminOnlyHandler)) - 注意
Subrouter不会自动继承父 router 的中间件，必须显式调用Use或手动包装
