可用http.servemux实现租户路由分发，需在中间handler中统一提取host/路径/请求头中的租户标识，校验后注入context并分发至租户专属handler，禁止动态注册mux或复用全局状态。
怎么用 http.ServeMux 实现租户路由分发
Go 标准库的 http.ServeMux 本身不支持路径前缀之外的动态路由匹配，所以不能直接靠它识别 tenant-a.example.com 或 /t/tenant-b/api/users 并自动跳转。必须在 handler 入口手动提取租户标识，再分发。
常见错误是试图注册多个 http.ServeMux 实例并混用 http.ListenAndServe，结果只有最后一个生效；或者把租户判断逻辑写在每个 handler 里，导致重复、难维护。
- 从
*http.Request中取租户标识，优先级建议：Host 头 > URL 路径前缀 > 请求头（如X-Tenant-ID） - 不要在
http.HandleFunc的回调里做租户解析和分发，统一收口到一个中间 handler，比如tenantRouter - 租户 ID 建议做白名单校验或正则过滤（如
^[a-z0-9][a-z0-9-]{2,29}$），避免路径遍历或注入类问题
func tenantRouter(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
tenant := extractTenant(r)
if tenant == "" {
http.Error(w, "tenant not found", http.StatusBadRequest)
return
}
// 把租户塞进 context，下游 handler 可用
ctx := context.WithValue(r.Context(), tenantKey, tenant)
r = r.WithContext(ctx)
next.ServeHTTP(w, r)
})
}
为什么不能直接用 gorilla/mux 的 Subrouter 做租户隔离
gorilla/mux 的 Subrouter 是静态配置，不支持运行时按请求动态挂载子路由。你无法在每次请求进来时“临时注册”一个 /t/{tenant}/ 下的完整路由树——它的路由表在 http.ListenAndServe 启动前就固定了。
典型误用：为每个租户 new 一个 mux.Router，然后在 handler 里调用 tenantRouter.ServeHTTP，结果发现中间件不生效、panic 在 panic: mux: couldn't find route。
- Subrouter 适合多环境（dev/staging/prod）或 API 版本（
/v1/、/v2/）这类固定分组，不适合租户这种数量不可预知、生命周期动态的场景 - 如果坚持用
gorilla/mux，正确做法是：主 router 提前注册通配路径（如PathPrefix("/t/{tenant}").Handler(tenantDispatcher)），再由tenantDispatcher拿到{tenant}后查表或加载对应 handler - 注意
gorilla/mux的变量捕获默认不校验格式，{tenant}可能匹配到/t/..%2fetc/passwd，务必加正则约束：PathPrefix("/t/{tenant:[a-z0-9][a-z0-9-]{2,29}}")
如何避免租户间 handler 状态污染
租户路由的核心风险不是分发失败，而是 A 租户的请求意外读到了 B 租户的缓存、DB 连接池、或全局变量状态。Go 的 goroutine 是轻量但共享内存的，一旦 handler 内部用了包级变量或未隔离的单例，就容易出事。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
最常踩的坑是：用 sync.Map 或 map[string]*sql.DB 存租户 DB 实例，但没做 key 清理，导致连接泄漏；或者在 middleware 里把租户信息写进全局 logger 实例，结果日志混杂。
- 租户级资源（DB、Redis client、配置）必须按租户 ID 构建并缓存，推荐用
sync.Map+ lazy init，key 是租户 ID，value 是封装好的 service 实例 - 禁止在 handler 函数外使用未加租户维度的包级变量（如
var currentUser *User） - 所有中间件若要记录租户上下文，必须从
r.Context().Value(tenantKey)获取，而不是从请求体或 header 重复解析
用 net/http 原生方式实现租户路由的最小可行代码
不用第三方库也能干净实现，关键是把租户提取、验证、分发三步拆清，且不依赖任何运行时注册机制。
下面这段可以直接跑起来，只依赖标准库：
func main() {
mux := http.NewServeMux()
mux.Handle("/", tenantRouter(http.HandlerFunc(defaultHandler)))
log.Fatal(http.ListenAndServe(":8080", mux))
}
func extractTenant(r *http.Request) string {
host := r.Host
if idx := strings.Index(host, "."); idx > 0 {
return host[:idx] // tenant-a.example.com → tenant-a
}
return ""
}
func tenantRouter(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
tenant := extractTenant(r)
if !validTenant(tenant) {
http.Error(w, "invalid tenant", http.StatusForbidden)
return
}
// 分发到租户专属 handler，例如 map[tenant]http.Handler
if h, ok := tenantHandlers[tenant]; ok {
h.ServeHTTP(w, r)
} else {
http.Error(w, "tenant not configured", http.StatusNotFound)
}
})
}
真正麻烦的从来不是怎么写这个分发器，而是租户 handler 里怎么确保 DB 查询只走该租户 schema、缓存 key 带租户前缀、日志字段不漏 tenant 字段——这些细节散落在业务逻辑各处，最容易被忽略。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
