gin.default() = gin.new() + use(logger(), recovery())，即创建带日志打印和panic恢复的engine实例；gin.new()返回空白引擎，无中间件，panic会导致服务崩溃。
gin.Default() 创建的不是“开箱即用”的黑盒，而是一个明确装配了 Logger 和 Recovery 中间件的 Engine 实例——它直接决定了你服务默认的日志行为和 panic 处理方式。
gin.Default() 和 gin.New() 的本质区别
二者都返回 *gin.Engine，但初始化状态完全不同：
-
gin.Default()内部调用gin.New()后，立刻执行engine.Use(Logger(), Recovery()) -
gin.New()返回的是完全空白的引擎：无中间件、无默认错误处理、无请求日志 - 生产环境若用
New()却忘了加Recovery，一次未捕获 panic 就会导致整个 HTTP server 崩溃退出 - 开发调试时用
Default()能快速看到请求路径、耗时、状态码；但日志格式不可定制，也不支持结构化输出（需自行替换Logger）
Engine 结构体里的 trees 字段到底存什么
Engine.trees 是一个 methodTrees 类型切片，每个元素对应一种 HTTP 方法（如 GET、POST），其内部是 Radix Tree（基数树）根节点。不是哈希表，也不是线性列表。
- 注册
r.GET("/user/:id")时，路径被拆解为["user", ":id"]，逐层插入到trees[0]（对应 GET 的树）中 - 节点字段
indices存的是子节点首字符（如 "u"、"o"），用于 O(1) 索引加速；children才是真实子树指针数组 - 相同前缀路径（如
/api/v1/users和/api/v1/products）天然共用树干，内存友好且匹配快 - 别误以为
trees是 map[string]*node——它靠下标索引方法类型，len(trees)固定为 9（对应 9 种标准方法）
Context 对象为什么能复用
gin.Context 不是每次请求 new 出来的，而是从 Engine.pool（sync.Pool）里取；响应结束后自动归还。这是 Gin 高性能的关键一环。
- 池中对象保留了字段零值（如
c.Request = nil），但复用了底层内存地址，避免频繁 GC - 不能在 goroutine 中跨协程传递
*gin.Context：一旦 handler 函数返回，该 Context 就可能被其他请求重用 - 若需在异步任务中访问请求上下文数据（如 traceID、userID），必须显式拷贝所需字段，而非传 Context 指针
- 自定义中间件里调用
c.Next()是链式执行关键：它不阻塞，只是推进c.index并调用下一个 handler，最后再折返执行后续逻辑
路由注册顺序影响匹配结果吗
影响，但只在特定冲突场景下暴露——Gin 不会报错或警告，而是静默按注册顺序覆盖。
- 先注册
r.GET("/user/:id", h1)，再注册r.GET("/user/new", h2)：后者能正常匹配，因为"new"是静态路径，与":id"参数节点不冲突 - 但如果反过来：先
/user/new，后/user/:id，则/user/new请求会被h1拦截（id = "new"），h2永远不会执行 - Gin 不做路由去重或优先级校验，
priority字段仅用于同级节点排序优化，不解决语义冲突 - 工程实践中应把静态路由写在动态路由之前，或统一用分组 +
HandleMethodNotAllowed控制 405 行为
真正容易被忽略的不是树怎么建，而是 sync.Pool 复用带来的生命周期陷阱：Context 里存的任何自定义字段（比如 c.Set("db", db)），若没在 handler 结束前清理，就可能污染下一个请求。
