Gin 的 RouterGroup 路由树不是哈希表，是前缀树（Trie）
很多人以为 Gin 路由快是因为用了 map 直接查路径，其实不是。gin.Engine 底层用的是自研的前缀树结构，支持动态注册、通配符（:id）、模糊匹配（*filepath），但代价是每次匹配都要逐字符比对节点。
这意味着：
– 静态路径（如 /api/users）匹配最快，O(m)，m 是路径长度
– 带参数的路径（如 /api/users/:id）要回溯判断是否冲突，最坏 O(n×m)
– 通配符路由（/*filepath）永远排在最后尝试，且一旦注册就禁用同级静态优化
- 避免在根路径或高频路径下滥用
*filepath，它会让整棵子树失去前缀剪枝能力 - 把
GET /users/:id和GET /users/:id/profile注册顺序调换，后者会被前者拦截——Gin 不做最长匹配，只按注册顺序 fallback - 静态路由尽量扁平：/v1/users 比 /api/v1/internal/users 更快，层级越深，树遍历开销越大
gin.RouterGroup.Use() 中间件不会影响路由匹配性能，但会拖慢实际请求
中间件本身不参与路由查找，gin.Engine 在匹配完路由后才组装 handler chain。但这里有个隐性陷阱：中间件执行时机在匹配之后、handler 之前，所以哪怕路由根本不存在，只要请求走到匹配阶段并成功落进某个 group，所有该 group 的中间件仍会执行一遍。
- 全局中间件（
engine.Use()）对每个请求都生效，包括 404；若含日志、鉴权、跨域等重逻辑，会浪费 CPU - 用
router.NoRoute()单独处理 404 时，记得也配一套轻量中间件，否则可能漏掉 CORS 或 traceID 注入 - 不要在中间件里做路径重写（如
c.Request.URL.Path = "/new"）再试图“重新匹配”，Gin 不支持运行时重入路由树
并发注册路由会 panic，但热更新必须靠重启或 fork
gin.Engine 的路由树不是线程安全的——任何时刻调用 GET、POST、Group() 都会直接修改底层 tree 结构。Go runtime 检测到写竞争时会直接 crash，错误信息是 fatal error: concurrent map writes（虽然实际不是 map，但 panic 机制复用了同一套检测）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 所有路由注册必须在
http.ListenAndServe之前完成，启动后不能再增删路由 - 想实现“配置化路由”？只能启动时读配置生成路由，或用
exec.Command("kill -HUP") + fork做进程级 reload - 别信网上那些“加 mutex 包一层就能热更”的方案——Gin 的树节点指针关系复杂，锁住注册函数没用，树内部 link 依然竞争
自定义 gin.HandlerFunc 里别做阻塞 IO，否则整个 M:N 协程池被拖垮
Gin 默认用 Go 原生 HTTP server，每个请求一个 goroutine。但路由匹配只是开始，真正卡住吞吐的是 handler 里的操作。比如在 func(c *gin.Context) 里调用 http.Get、os.Open、time.Sleep，会导致该 goroutine 长时间阻塞，而 Go runtime 不会自动调度其他任务进来。
- 数据库查询务必用 context 带 timeout，例如
db.WithContext(c.Request.Context()).Find(&u) - 文件读写优先走异步封装（如
io.CopyBuffer+bytes.Buffer），别用ioutil.ReadFile这种全量加载函数 - 第三方 SDK 若不支持 context（如老版本
redis-go），至少用net.DialTimeout控制建连，否则 DNS 卡住 30 秒，整个连接池就僵死
路由快不代表服务快，Gin 的性能优势只在匹配层；真正压垮系统的，往往是 handler 里那行没加 context 的 http.Post。
