路由匹配先于中间件执行，gin用radix树o(log n)匹配路径和方法，确定handler后才执行中间件链；匹配失败时group中间件不执行，但全局中间件仍执行。
路由匹配发生在中间件执行之前
所有中间件（包括 engine.Use()、group.Use()、单路由中间件）都**不参与路由查找过程**。Gin 先用 Radix 树完成路径 + 方法的 O(log n) 匹配，确定目标 handler 后，才开始组装并执行中间件链。这意味着：即使你注册了 50 个中间件，它们对匹配耗时零影响；但若路由根本不存在，只要请求落入某个 group 范围（比如 /api/xxx 匹配到 router.Group("/api")），该 group 下所有 Use() 中间件仍会执行一遍——哪怕最终走的是 NoRoute。
中间件执行时机取决于路由是否匹配成功
这是最容易被忽略的隐性成本点：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 匹配成功：按洋葱模型执行，
c.Next()控制流向 handler - 匹配失败（404）：若没显式定义
router.NoRoute()，请求会落到默认 404 处理器，此时 全局中间件仍会完整执行，但 group 级中间件不会——因为没进入任何 group 分支 - 你写了
router.NoRoute(mw1, mw2, handler)，那mw1和mw2就只在 404 时运行；但若漏配，CORS、traceID 注入等就可能在 404 响应里丢失
:id 和 *filepath 不影响匹配顺序，但决定能否进入分支
Gin 的 Radix 树构建后就固化，注册顺序无关紧要。真正起作用的是路径结构本身：
-
:id是单段占位符，匹配/user/123中的123，不能跨/；写成/user/{id}或/user/*id直接 404 -
*filepath必须位于路径末尾，如/static/*filepath，它吃掉后续全部路径段；放中间或开头会被忽略 - 中间件里如果依赖
c.Param("id")，但 handler 还没执行，c.Param就是空——因为参数解析实际发生在 handler 内部绑定阶段，不是路由匹配时填的
Abort() 不跳过已执行的中间件前置逻辑
c.Abort() 只是阻止后续中间件和 handler 执行，**已经跑过的前置代码不会回滚**：
- 日志中间件在
c.Next()前打了开始时间，后面c.Abort()了，你不会自动得到“结束时间”或状态码 - 鉴权中间件调用
c.AbortWithStatusJSON(401, ...)后，响应头已发，但c.Writer.Status()仍返回 0——得用c.Writer.StatusWritten判断是否已发头 - 别在中间件里做
c.Request.URL.Path = "/new"试图重匹配，Gin 不支持运行时重入路由树，改了也没用
NoRoute 配置和 Abort() 行为里——这些地方一疏忽，性能毛刺和逻辑错乱就会悄无声息地出现。
