Gin 框架本身不支持多子域名路由隔离，因其路由树仅基于 HTTP 方法和路径构建，不感知 Host 头；正确做法是在 Gin 外层用 http.ServeMux 或反向代理（如 Nginx、Caddy）按 Host 分流到不同 gin.Engine 实例。
Go 语言中 Gin 框架本身不支持多子域名路由隔离 —— 它只处理 HTTP 请求的 Host 头和路径，不内置虚拟主机（vhost）级路由分发。想实现 api.example.com、admin.example.com、www.example.com 各走不同路由树，必须在 Gin 外层手动分流。
为什么 Gin 的 Group 不能解决子域名问题
Gin 的 r.Group("/api") 只作用于 URL 路径前缀，对 Host 头完全无感知。无论请求来自 api.example.com 还是 www.example.com，只要路径是 /users，就会匹配到同一组路由。Gin 的路由树（methodTrees）只按 HTTP 方法 + 路径构建，不包含 Host 维度。
-
r.Group()返回的是*gin.RouterGroup，其basePath字段仅拼接路径，不参与 Host 匹配 - 所有 Group 最终注册到同一个
Engine.trees，Host 判断必须在进入 Gin 前完成 - 试图用
c.Request.Host在 handler 里做分支，会导致中间件、日志、恢复等逻辑混杂，违背分层设计
正确做法：用 http.ServeMux 或反向代理前置分流
最轻量且可控的方式，是在 Gin 实例之上套一层标准 http.ServeMux，按 Request.Host 分发到不同 gin.Engine 实例：
func main() {
// 创建多个独立 Engine
apiRouter := gin.New()
apiRouter.GET("/users", func(c *gin.Context) { c.String(200, "API") })
adminRouter := gin.New()
adminRouter.GET("/dashboard", func(c *gin.Context) { c.String(200, "Admin") })
// 用标准 http.ServeMux 做 Host 分流
mux := http.NewServeMux()
mux.HandleFunc("api.example.com/", func(w http.ResponseWriter, r *http.Request) {
r.URL.Path = strings.TrimPrefix(r.URL.Path, "/") // 去掉 host 前缀
apiRouter.ServeHTTP(w, r)
})
mux.HandleFunc("admin.example.com/", func(w http.ResponseWriter, r *http.Request) {
r.URL.Path = strings.TrimPrefix(r.URL.Path, "/")
adminRouter.ServeHTTP(w, r)
})
http.ListenAndServe(":8080", mux)
}
- 每个子域名对应一个独立
gin.Engine，中间件、日志、恢复互不影响 - 注意手动修正
r.URL.Path：因为ServeMux会把完整路径（含 host）传入，而 Gin 只认路径部分 - 若用 HTTPS，需确保 TLS 终止在 Go 进程前（如 Nginx/Cloudflare），或使用
http.Server.TLSConfig配置 SNI
生产环境更推荐反向代理方案
直接在 Go 中做 Host 分流虽可行，但缺失连接复用、健康检查、证书自动续期等能力。真实项目应交由专业反向代理处理：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
立即学习“go语言免费学习笔记（深入）”；
- Nginx 配置示例：
server_name api.example.com;→proxy_pass http://127.0.0.1:8081; - Caddy 支持自动 HTTPS：
api.example.com { reverse_proxy localhost:8081 } - Kubernetes Ingress 通过
host字段路由到不同 Service - 此时每个 Gin 应用只需监听不同端口（如
:8081、:8082），专注业务逻辑
容易踩的坑：Host 头伪造与通配符匹配
直接读取 c.Request.Host 不安全 —— 客户端可随意伪造该 header。必须依赖底层 TCP 连接的真实 SNI 或反向代理的可信转发头：
- 若用 Nginx，加
proxy_set_header X-Forwarded-Host $host;，然后在 Gin 中校验c.GetHeader("X-Forwarded-Host") - 避免写
strings.Contains(c.Request.Host, "api.")—— 会被evil-api.example.com绕过 - 不要用通配符子域名（如
*.example.com）自动创建路由组 —— Gin 没有运行时动态注册机制，必须提前定义好每个子域名对应的 Engine
子域名隔离本质是网络层或反向代理层的责任，Gin 只负责路径级路由。强行在框架内“模拟”只会让代码脆弱、难测试、难维护。
