gin.Default()自动注册Logger和Recovery中间件，提供请求日志与panic恢复能力；gin.New()返回空白引擎，所有中间件、路由、配置均需手动添加，适用于需自定义日志或高可控性的生产环境。
gin.Default() 和 gin.New() 的区别在哪
直接决定你项目启动时有没有默认中间件，不是风格偏好，是生产环境是否裸奔的问题。
gin.Default() 会自动注册 Logger() 和 Recovery() 两个中间件：前者打请求日志，后者捕获 panic 防止服务崩溃。而 gin.New() 返回一个完全空白的 *gin.Engine，连路由树都是空的，所有中间件、路由、配置都得自己加。
- 开发调试阶段用
gin.Default()更省心，但要注意日志格式不可控，高并发下Logger()可能成为瓶颈 - 生产环境若需自定义日志（比如对接 Loki 或结构化 JSON 日志），必须用
gin.New()，再手动挂载自己的中间件 -
Recovery()虽然防 panic，但它只是 recover + 返回 500，不记录堆栈详情；真要排查问题，得配合gin.RecoveryWithWriter()把 panic 写进文件或 stderr
Engine 是怎么接管 net/http 的 ServeHTTP 的
Gin 没有重写 HTTP 底层，它只是实现了 http.Handler 接口，把标准库的请求生命周期接了过来。
当你调用 r.Run()，本质是执行 http.ListenAndServe(":8080", r)，其中 r 就是 *gin.Engine——它实现了 ServeHTTP(http.ResponseWriter, *http.Request) 方法。这个方法内部做了三件事：初始化 gin.Context、走中间件链、匹配路由树并执行 handler。
- 每次请求进来，
Engine.ServeHTTP都会从sync.Pool取一个复用的gin.Context，避免频繁 GC - 中间件链通过
c.Next()控制执行时机：调用前是“前置处理”，c.Next()返回后是“后置处理” - 如果中间件里没调用
c.Next()（比如鉴权失败直接c.Abort()），后续中间件和最终 handler 就不会执行
Radix 树路由匹配到底快在哪
不是“比遍历快”，而是“根本不用遍历”。Gin 对每个 HTTP 方法（GET/POST 等）单独维护一棵压缩前缀树（Radix Tree），路径匹配时间复杂度接近 O(1)。
比如注册了 /api/v1/users/:id 和 /api/v1/files/*path，Gin 不会把它们当字符串去正则或分割比较，而是按字符逐级构建树节点。请求 GET /api/v1/users/123 进来时，先定位到 GET 树，再按 /api/v1/users/ 走固定路径分支，最后把 123 绑定到 :id 参数。
- 通配符
*path是树的“兜底叶子节点”，优先级最低；路径参数:id是“动态节点”，优先级高于通配符但低于静态路径 - 重复注册相同路径不同方法（如
GET /user和POST /user）完全没问题，它们落在不同的树上 - 注意：树只认路径结构，不解析查询参数（
?page=1），那部分得靠c.Query()手动取
Context 生命周期里哪些操作容易泄漏或阻塞
gin.Context 是一次请求的上下文载体，但它的几个常用方法背后有隐含行为，不注意就会出问题。
-
c.Bind()和c.ShouldBindJSON()会读取整个请求 body，如果前端发了个超大 JSON（比如 100MB），它会一次性加载进内存，可能 OOM；应提前用c.Request.ContentLength做大小校验 -
c.Copy()用于 goroutine 安全，但复制的是指针引用，如果原Context已结束（比如 handler 返回了），子 goroutine 里再调c.JSON()会 panic —— 必须用c.Request.Context().Done()监听取消信号 -
c.Set()存的数据只在当前请求生命周期有效，不能当全局缓存用；跨请求传值要用外部存储（Redis、context.Value 配合 middleware 注入）
最常被忽略的一点：Context 本身不持有 request/response 的所有权，它只是包装；真正决定连接是否关闭的，是 http.ResponseWriter 是否被写入、以及底层 TCP 连接状态。别以为 c.Abort() 就万事大吉，该 flush 的 header 还是要 flush。
