必须用Group()绑定中间件，不能靠c.Request.URL.Path字符串匹配——因反向代理会重写路径、权限逻辑易膨胀、丧失O(1)路由性能；正确做法是为各渠道商创建独立分组并显式挂载中间件。
必须用路由分组绑定中间件，不能靠路径字符串匹配或手动拼接前缀来“模拟”拦截逻辑——Gin 的 Group() 机制才是唯一可靠、可维护的渠道商隔离方式。
为什么不能用 c.Request.URL.Path 匹配渠道商路径？
手动检查 c.Request.URL.Path 是否包含 /channel/a123 这类字符串，看似简单，但会踩三个坑：
- 路径可能被反向代理重写（如 Nginx 去掉前缀），
c.Request.URL.Path已失真 - 多个渠道商共用同一组 handler 时，权限校验逻辑混杂，
if channel == "a123"会迅速膨胀成难以测试的条件树 - 无法享受 Gin 路由树的 O(1) 匹配性能，每次请求都做字符串扫描，无谓消耗 CPU
正确做法：为每个渠道商创建独立路由分组
用 Group() 显式声明渠道商边界，路径前缀自动合并，中间件天然隔离：
r := gin.Default()
// 渠道商 A 专用分组，所有子路由自动带 /channel/a123 前缀
a123 := r.Group("/channel/a123")
a123.Use(ChannelAuthMiddleware("a123")) // 传参定制化校验
a123.GET("/products", listProductsHandler)
a123.POST("/orders", createOrderHandler)
// 渠道商 B 分组，完全独立的中间件和 handler
b456 := r.Group("/channel/b456")
b456.Use(ChannelAuthMiddleware("b456"))
b456.GET("/products", listProductsHandler) // 复用业务逻辑，但上下文已隔离
注意：/channel/a123 必须以单个 / 开头，且不能是 /channel/a123/（尾部斜杠会导致 301 重定向）。
ChannelAuthMiddleware 里怎么提取并校验渠道商身份？
分组路径前缀只是入口标识，真实校验必须依赖可信凭证（如 header 中的签名或 JWT），不能只信 URL：
- 在中间件中调用
c.Param("channel_id")无法获取分组前缀——Gin 不把 Group 前缀当参数解析 - 应从
c.GetHeader("X-Channel-Signature")或c.MustGet("user_token")（若上游已解析）中提取渠道商 ID - 校验失败时必须调用
c.AbortWithStatusJSON(403, ...)，不能只return，否则后续中间件仍会执行 - 校验通过后建议用
c.Set("channel_id", "a123")注入上下文，供下游 handler 安全使用
全局中间件 + 分组中间件叠加时的执行顺序陷阱
如果同时注册了全局日志中间件和渠道商分组中间件，执行顺序是固定的洋葱模型：
全局 Logger → 渠道商 Auth → handler → 渠道商 Auth（后置） → 全局 Logger（后置）
这意味着：
- 渠道商中间件里的
c.Next()之后的代码，能读到全局中间件设置的字段（如c.Get("start_time")） - 但不要在渠道商中间件里覆盖全局中间件已设的 key（如
c.Set("user_id", ...)），否则日志中间件可能误记为渠道商 ID - 若需区分日志来源，建议在渠道商中间件里加
c.Set("log_prefix", "[channel-a123]")，再让全局日志中间件读取该字段
最易忽略的一点：分组中间件的 c.Abort() 只终止该分组内的调用链，不会跳过全局中间件的后置逻辑——所以日志中间件仍会打印状态码，但此时 c.Writer.Status() 可能是 0（未写响应）或 403（已 Abort），务必判断清楚。
