Gin 不支持传统控制器继承，因其基于函数式设计且 Go 无原生类继承；应通过嵌入结构体+显式传入 *gin.Context 的通用方法实现复用，并优先使用 RouterGroup 分组管理路由与中间件。
为什么 Gin 本身不支持传统意义上的控制器继承
Gin 是基于函数式风格设计的，RouterGroup 和 handler 函数之间是纯组合关系，没有类或继承语法支撑。所谓“控制器继承”，其实是 Go 语言中通过结构体嵌套 + 方法接收者模拟出来的模式，并非语言原生特性。直接写 type AdminController struct { BaseController } 看似继承，但若 BaseController 中的方法不显式调用 c（即 *gin.Context），就无法共享中间件、错误处理、日志等上下文能力。
用嵌入结构体 + 公共方法实现可复用基类
真正的可行路径是定义一个基础结构体，把通用逻辑封装为方法，再让业务控制器嵌入它。关键点在于：所有方法必须接收 *gin.Context，且不能依赖 receiver 的字段状态（因为每次请求都新建 controller 实例）。
-
BaseController不应保存任何请求相关状态（如userID、token），这些应从c中实时提取 - 通用方法如
SuccessJSON(c *gin.Context, data interface{})或FailJSON(c *gin.Context, code int, msg string)必须显式传入c - 避免在嵌入结构体里定义
Init()或构造函数——Gin 路由注册时只调用方法，不实例化整个树 - 示例：
type BaseController struct{}<br>func (b *BaseController) SuccessJSON(c *gin.Context, data interface{}) {<br> c.JSON(200, gin.H{"code": 0, "data": data})<br>}
多级路由分组比“继承”更符合 Gin 原生设计
大型项目中真正需要的是清晰的层级隔离和中间件复用，而不是面向对象式的继承链。Gin 的 Group() 天然支持嵌套，这才是官方推荐且性能无损的方式：
- 一级分组按模块（如
/api/v1），二级按资源（如/users），三级按操作（可选，如/admin） - 每个分组可挂载专属中间件：
authMiddleware只加在/admin组，不影响/public - 路径拼接自动完成：
v1.Group("/users").Group("/profile")→ 最终路径是/api/v1/users/profile - 避免手动拼接字符串路径，否则易出错且不可维护
容易被忽略的陷阱：中间件执行顺序与 Group 嵌套深度
中间件不是“绑定到 controller”，而是绑定到 RouterGroup 实例。嵌套过深时，中间件会层层叠加，但不会自动去重或跳过：
立即学习“go语言免费学习笔记（深入）”；
- 如果
v1 := r.Group("/api/v1")注册了logger，而admin := v1.Group("/admin")又注册了一次logger，那么每个 admin 请求会执行两次日志记录 - 全局中间件（
r.Use(...)）对所有路由生效，包括NoRoute；而分组中间件只作用于该组及其子组 - 不要在 controller 方法里重复做鉴权或参数校验——这些应该在对应 Group 的中间件里统一拦截
- 调试时用
c.FullPath()查看当前匹配路径，确认是否被意外的父级 Group 中间件提前终止
