整体架构

Gin 的核心不是某一个路由算法，而是把路由索引、请求状态和 handler 执行链压缩成一条短路径。

先给答案：Gin 是在 net/http 上加了一层索引和一次对象复用，没有自己的并发模型

Engine 本身就是一个 http.Handler，请求进来只做三件事：从 sync.Pool 取一个 Context、在注册期建好的 Radix 树上按“方法 + 路径”定位 handler 链、顺序执行这条链。路由树只在注册期写、请求期只读，因此匹配过程无锁；Context 把参数、中间件状态和响应写入器收在一个对象里，请求结束后归还池子。

因此 Gin 的性能来源是“每请求少分配 + 匹配更快”，连接与 goroutine 的调度仍然由 net/http 提供，它并没有重写服务器。代价也正落在复用上：*gin.Context 的生命周期严格等于一次请求，任何把它带进后台 goroutine 或缓存起来的写法，读到的都可能是另一个请求的数据——这是 Gin 最高频的线上事故形态。

分层

net/http
   |
Engine.ServeHTTP
   |
methodTrees -> node.getValue -> handlers
   |                         |
RouterGroup.handle       Context.Next
   |                         |
binding / render       ResponseWriter

层	核心抽象	主要职责
接入层	Engine	实现 http.Handler，选择方法树并处理 404/405/redirect
组织层	RouterGroup	组合前缀、middleware 和终端 handler
索引层	node	压缩路径、静态分支、参数分支和 catch-all
执行层	Context	保存请求状态，推进 handlers chain，写响应
输入层	binding.Binding	将请求数据解码并调用结构校验

核心抽象

Engine 持有 trees、全局 404/405 handlers 和 sync.Pool，见 gin.go:92、gin.go:183。New 在 gin.go:202 初始化默认配置，并在 gin.go:225 设置池工厂。

RouterGroup 把 middleware 保存在扁平 HandlersChain 中；Group 在 routergroup.go:72 创建带新前缀的子组，handle 在 routergroup.go:86 计算完整路径并注册。

node 是压缩树节点，字段 path 存一段公共边，indices 用首字节索引静态孩子，结构见 tree.go:99。请求匹配返回 nodeValue，不仅有 handlers，还有参数、完整路径和 trailing-slash 建议，见 tree.go:407。

Context 把 Request、Writer、Params、handlers 和 index 放在一次请求状态里，定义见 context.go:61。binding 通过 Binding、BindingBody 和 StructValidator 解耦协议格式与业务结构，见 binding/binding.go:32。

主流程一：初始化与注册

New()
  -> pool.New = allocateContext
  -> Use() 合并全局 middleware
  -> Group()/GET()
  -> combineHandlers()
  -> addRoute()
  -> method tree.addRoute()

1. gin.New 创建 Engine；Default 额外安装 Logger 和 Recovery，见 gin.go:236。
2. Engine.Use 在 gin.go:340 更新全局 chain，并重建 404/405 chain。
3. RouterGroup.combineHandlers 在 routergroup.go:241 预分配并复制父子 handlers。
4. Engine.addRoute 在 gin.go:364 按 HTTP method 找到或创建 root，并更新最大参数数。
5. node.addRoute 在 tree.go:135 按最长公共前缀拆分边，再插入静态或 wildcard 节点。

主流程二：请求处理

HTTP request
  -> ServeHTTP
  -> pool.Get + reset
  -> handleHTTPRequest
  -> method tree.getValue
  -> Context.Next
  -> WriteHeaderNow
  -> pool.Put

ServeHTTP 的完整池化边界位于 gin.go:662：取 Context、重置 writer、设置 Request、执行请求、归还池。handleHTTPRequest 在 gin.go:690 选择方法树，tree.getValue 匹配并写入 Params，命中后调用 c.Next()，最后确保响应头写出。

扩展点全景

扩展点	位置	触发时机
全局 middleware	Engine.Use	每个请求，包括 404/405
分组 middleware	RouterGroup.Group	某个前缀下的请求
自定义绑定	binding.Binding	ShouldBindWith
自定义校验	binding.Validator	binding 解码后
404/405	NoRoute / NoMethod	路由匹配失败
重定向	RedirectTrailingSlash	tree 返回 tsr

为什么采用分层对象而不是一个 Router

替代方案：让单个 Router 同时负责路径索引、请求状态、绑定和响应。 为什么不行：注册期数据结构和请求期可变状态生命周期不同，混在一起会让并发安全、复用和扩展边界不清。 证据：Engine 只在 gin.go:364 注册树，Context 在 context.go:103 重置请求状态，binding 则由 binding.Binding 接口隔离。

边界与踩坑

场景	现象	原因	规避
注册后并发改路由	数据竞争或树状态异常	node.addRoute 明确非并发安全	启动阶段完成注册
middleware 太长	每次请求遍历更多 handler	chain 是扁平数组	合并公共逻辑，避免重复 middleware
404/405 自定义遗漏	错误响应没有统一日志	Use 会重建专用 chain，但仅已注册 middleware 生效	在 Use 前后确认 NoRoute/NoMethod
Context 跨请求保存	数据串请求	Context 会被池化重置	异步场景使用 Copy

可迁移知识

• 将“注册期索引”和“请求期状态”拆开，容易获得更清晰的并发边界。
• 扁平 chain 比嵌套对象更容易做统一前后置执行，也便于快速跳过。
• 返回结构体式的匹配结果，比只返回 handler 更适合承载 redirect、参数和诊断信息。

面试锚点

• Gin 的请求主链路如何从 http.Handler 进入路由树？
• 为什么 Context 可以池化而路由树不能在请求期修改？
• RouterGroup 如何把父子 middleware 合并成一条 chain？

Related

• Radix 树路由匹配
• Context 复用与 sync.Pool
• 中间件与 Abort