路由分组本质是作用域隔离与中间件绑定的组合，需严格遵循路径前缀规范（必须以/开头、避免重复拼接）、显式调用Use()绑定中间件、避免嵌套过深，并注意通配符冲突与静态路径覆盖规则。
路由分组不是“加个前缀就完事”，它本质是作用域隔离 + 中间件绑定的组合动作，不显式挂载中间件、乱用嵌套或忽略路径冲突规则，轻则权限失效，重则启动 panic。
Group 路径前缀必须以 / 开头，且不能重复拼接
写 r.Group("/api/v1") 后，再注册 .GET("/user")，最终路径是 /api/v1/user；如果误写成 .GET("/api/v1/user")，实际变成 /api/v1/api/v1/user —— 这类错误在调试时很难一眼发现，但会导致 404。
- 路径末尾是否带
/有区别：r.Group("/api")和r.Group("/api/")是两个不同前缀，后者注册.GET("")对应的是/api//xxx - 不要手动拼接字符串做分组，比如
r.GET("/api/v1" + "/user", handler)—— 这绕过了 Group 的作用域机制，中间件不会生效 - 版本号、模块名这类前缀建议统一定义常量，避免散落在各处：
const APIV1 = "/api/v1"
中间件必须显式调用 Use()，分组本身不带任何逻辑
Group 返回的是 *gin.RouterGroup，它不自动继承全局中间件，也不自带鉴权或日志。常见错误是以为 “/admin 分组天然需要登录”，结果忘了调 admin.Use(JWTAuth())，导致所有接口裸奔。
- 全局中间件（如
recovery、logger）应在gin.Default()或gin.New()后立即.Use()，而不是塞进某个分组里 - 父子分组之间中间件不自动传递：父组
v1.Use(Auth)不影响子组v1.Group("/admin")，后者仍需自己.Use(Auth, RoleRequired("admin")) - 多个中间件顺序敏感：
group.Use(m1, m2)表示请求先过m1再m2，响应则逆序；若m2依赖m1注入的上下文字段，顺序反了就 panic
嵌套分组要命名变量，避免链式调用掩盖作用域
写 r.Group("/api").Group("/v1").Group("/admin").GET("/users", handler) 看似简洁，实则难以调试、无法复用、中间件绑定位置模糊。真正可控的做法是显式赋值。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 推荐写法：
v1 := r.Group("/api/v1"); admin := v1.Group("/admin").Use(Auth, AdminOnly) - 这样
admin变量只作用于其下路由，和v1.Group("/user")完全隔离，不会误共享中间件 - 嵌套过深（超过 3 层）通常是设计信号：该拆分成独立模块或文件了，而不是硬塞在一个分组链里
分组后必须注意路由冲突与通配符限制
Gin 的路由树是扁平注册的，所有分组最终都落到同一个 Engine 上。这意味着路径冲突不是“分组内报错”，而是整个服务启动失败。
- 典型 panic：
wildcard route conflicts with existing children，通常是因为在带通配符的分组（如r.Group("/files/:name")）里又注册了静态路径.GET("/files/logo.png") - 通配符（
:id、*filepath）只能出现在分组前缀之后，且不能和同级静态路径共存；想同时支持/files/:name和/files/download/:name，得拆到不同分组或用Any()+ 手动判断 - 相同 HTTP 方法 + 相同路径，后注册的会覆盖前注册的 —— 比如
v1.GET("/user", a)和v2.GET("/user", b)共存时，v2的 handler 实际生效，v1的被静默替换
最易被忽略的一点：分组只是语法糖，不是沙箱。它不改变变量作用域、不隔离 panic 恢复、不自动管理资源生命周期。所有 handler 共享同一个 *gin.Context 生命周期，中间件没 abort、handler 里没 defer 关数据库连接，照样泄漏。
