Gin生命周期核心是Engine、Context与路由树协同：Engine为静态容器，仅启动时创建一次，持有按HTTP方法分组的Radix树、Context对象池及路由配置；Context为每次请求的动态载体，从pool复用并重置，处理完归还；路由树在启动时构建，请求时依method定位树并路径匹配。
Gin 的生命周期核心不是“启动→运行→关闭”这种线性流程，而是围绕 Engine、Context 和路由树三者协作展开的——其中 Context 是真正贯穿每次请求的唯一载体，而 Engine 本身几乎不随请求变化。
Engine 是静态容器，不是每次请求都新建
gin.Default() 或 gin.New() 返回的 *gin.Engine 实例，在整个服务生命周期中只创建一次。它内部持有：
-
trees：按 HTTP 方法（GET、POST等）分组的多棵 Radix 树，注册路由时就写入，后续只读 -
pool sync.Pool：用于复用*gin.Context对象，避免高频 GC -
RouterGroup：根路由组，承载全局中间件和基础配置（如RedirectTrailingSlash）
你调用 r.GET("/path", handler) 时，实际是往对应方法的 Radix 树里插入节点；r.Use(mw) 则把中间件追加到 Engine.Handlers 切片。这些操作都在启动前完成，运行时不再修改 Engine 结构。
Context 是每次请求的“活实例”，用完即归还
每个 HTTP 请求到来时，Engine.ServeHTTP 从 pool 取出一个 *gin.Context，重置其字段（Request、Writer、Handlers、index 等），再注入当前请求数据。处理结束后，c.Abort() 或自然执行完所有中间件后，Context 被清空并放回 pool。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
关键点：
- 不能在 goroutine 中跨请求保存
*gin.Context指针——它会被复用，下次请求内容已覆盖 -
c.Copy()只深拷贝部分字段（如Params、Keys），不复制Request或Writer，仅适用于派生子请求 - 中间件间传值必须用
c.Set("key", val)+c.Get("key")，而非局部变量
Radix 树匹配发生在请求进入的毫秒级内
Gin 不是遍历所有注册路由，而是根据 req.Method 定位到对应方法树（如 engine.trees[0] 对应 GET），再用路径字符串逐字符匹配 Radix 树节点。这意味着：
-
/user/:id和/user/:id/posts在树中是父子关系，不是正则模糊匹配 -
/files/*filepath这种通配符由树中特殊节点标记，匹配逻辑硬编码在tree.getValue()里 - 路径中带查询参数（
?a=1&b=2）不影响树匹配，c.Query("a")是从c.Request.URL.Query()解析，与路由树无关
中间件链执行依赖 index 字段控制流转
Context 的 index 字段是整型游标，默认为 -1。每次调用 c.Next() 时，index 自增并执行下一个 HandlerFunc；c.Abort() 则直接将 index 设为 int8(len(c.Handlers))，跳过剩余中间件。
典型陷阱：
- 在中间件里忘了调用
c.Next()，后续所有中间件和最终 handler 都不会执行 - 在
c.Next()后继续写响应（如c.JSON(200, ...)），可能触发 “http: multiple response.WriteHeader calls” panic - 使用
c.Redirect()后未跟c.Abort()，会导致重定向后仍继续执行后续逻辑
真正容易被忽略的是：Context 的生命周期严格绑定单次请求，它的复用机制决定了任何对 Context 的长期引用（比如塞进 map 缓存、传给异步 goroutine）都是危险的——那不是“你的上下文”，只是下一个请求的临时容器。
