Gin通过中间件读取Host头实现跨域名路由分发，需在路由注册前解析Host并设置上下文或重写路径，避免误用Group路径模拟域名、忽略端口清理及租户上下文透传不一致等问题。
如何用 Host 头匹配实现跨域名路由分发
Gin 本身不提供基于 Host 的原生路由分组，但可以通过中间件提前读取 Host 请求头，再手动跳转或复用不同 *gin.Engine 实例——最稳妥的方式是用单个 Engine + 中间件做路由前判断，避免启动多个服务实例带来的维护和端口冲突问题。
常见错误现象：直接在 r.Group() 里写 /example.com/users 这类路径，Gin 会把它当普通路径处理，完全忽略 Host；或者误以为 router.Host("api.example.com") 是 Gin 内置 API（实际不存在）。
- 必须在所有路由注册前，用
c.Request.Host或c.GetHeader("Host")获取原始 Host 值（注意：反向代理后可能需读X-Forwarded-Host） - 不要在中间件里调用
c.Next()后再修改路由，Gin 的路由匹配已在c.Next()前完成，此时改无效 - 推荐做法：中间件根据 Host 设置一个自定义上下文键（如
c.Set("domain", "admin.example.com")），后续 handler 再分支处理；或直接用c.Redirect()转到预设路径前缀（如/admin/xxx）
同一个 Engine 下按 Host 复用不同路由组
核心思路是把域名差异“翻译”成路径前缀差异，再交给 Gin 原有路由机制处理。比如 user.example.com → 自动前置 /user，admin.example.com → 前置 /admin，然后复用已定义的 r.Group("/user") 和 r.Group("/admin")。
性能影响很小，因为只是字符串比较 + 一次 c.Request.URL.Path 重写，无额外 goroutine 或锁竞争。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 在全局中间件中判断：
if c.Request.Host == "user.example.com" { c.Request.URL.Path = "/user" + c.Request.URL.Path } - 注意路径重复问题：若原始请求是
/api/profile，重写后变成/user/api/profile，对应路由必须注册为userGroup.GET("/api/profile", ...)，不能漏掉/user/前缀 - 如果 Host 值含端口（如
localhost:8080），建议用strings.TrimRight(c.Request.Host, ":80"):80统一清理，或直接用http.Request.URL.Hostname()
多域名共用时中间件作用域易混淆的坑
很多人以为给 r.Group("/user") 加了日志中间件，那所有来自 user.example.com 的请求就自动带日志——错。中间件只绑定在路径前缀上，和 Host 无关。Host 判断必须显式写在中间件里，否则同一路径下不同域名的请求会混用同一套中间件逻辑。
- 正确写法：定义一个闭包中间件
func(domain string) gin.HandlerFunc，在内部判断c.Request.Host == domain再决定是否执行鉴权、日志等逻辑 - 错误写法：
userGroup.Use(AuthMiddleware)然后指望它只对user.example.com生效——它对所有匹配/user/*的请求都生效，无论 Host 是啥 - 如果真要隔离，只能为每个域名启一个独立
gin.Engine实例并监听不同端口（如:8081、:8082），但运维成本陡增，不推荐
泛域名（wildcard domain）匹配怎么写
比如支持 tenant1.example.com、tenant2.example.com，需要提取子域名并透传给 handler。Gin 不支持通配符 Host 匹配，得自己解析。
- 用
strings.Split(c.Request.Host, ".")拆分，取第一个片段作为 tenant ID；注意处理www.example.com这类边缘情况 - 别用正则做 Host 匹配——高频请求下正则编译和执行开销明显，简单
strings.HasSuffix或strings.Contains更快 - 提取后的 tenant ID 应存入 context：
c.Set("tenant", tenantID)，后续 handler 统一从c.MustGet("tenant").(string)读取，避免重复解析 - 若需结合 JWT 中的 tenant 字段做校验，务必在此中间件之后、业务 handler 之前做一致性检查，防止 Host 头被伪造
真正麻烦的不是怎么写 Host 判断，而是后续所有 handler 都得适配多租户上下文——比如数据库连接池、缓存 key 前缀、日志字段，这些地方漏一处，就可能跨租户泄露数据。
