核心是租户id必须在首个中间件解析并存入ctx.locals，通过子域名/headers/jwt提取且不fallback，默认失败返回400；禁用group静态路由，需动态db连接池与显式透传租户上下文至异步任务。
直接用 Fiber 做多租户路由区分，核心不是靠“自动识别”，而是你得在第一个中间件里把租户 ID 解析出来、存进上下文，并确保后续所有数据库操作、缓存键、日志标记都基于它——漏掉任意一环，数据就可能串。
如何从 Host 或 Header 提取 tenant_id 并透传到整个请求生命周期
租户识别必须在 fiber.Next() 之前完成，且不能依赖全局变量（var tenantID string）或普通闭包变量（会跨请求污染）。Fiber 的 Ctx.Locals 是安全的，但只在当前请求有效；异步任务（如 Goroutine 或第三方队列）需显式携带该值。
- 子域名方式（推荐）：
ctx.Hostname()解析出tenant1.example.com→ 取tenant1 - Header 方式（适合内部调用）：
ctx.Get("X-Tenant-ID")，必须校验非空且在白名单内 - JWT Token 方式（需前置鉴权）：先验签，再从 payload 里取
tenant_id字段，不能跳过验签直接读 - 绝对不要 fallback 到默认租户：识别失败应直接
ctx.Status(400).SendString("tenant not found")
为什么不能用 fiber.Group("/tenant1") 这种静态前缀做租户隔离
fiber.Group 是编译期路由分组，适用于功能模块（如 /api/v1/admin），不适用于运行时动态租户。一旦写死 /tenant1，你就得为每个新租户手动加路由、重启服务，完全违背多租户可扩展前提。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 真实场景中租户是动态增删的，可能每天新增几十个，不可能改代码发版
- Group 路由无法和数据库连接池、缓存命名空间联动，你没法根据路径前缀自动切换
sql.DB - 前端请求带
/tenant2/product/list，后端却只注册了/tenant1/...，结果就是 404，而不是租户不存在
如何让每个租户走独立数据库连接且不泄漏连接池
Fiber 本身不管理数据库，但你必须避免两个常见错误：一是复用同一个 *sql.DB 实例给所有租户，二是启动时就把全部租户库全连一遍。正确做法是按需创建、带缓存、设限。
- 维护一个
map[string]*sql.DB缓存租户 DB 实例，key 是tenant_id，value 是带独立连接池的*sql.DB - 首次访问某租户时，用
sql.Open("pgx", tenantDSN)创建，显式设置SetMaxOpenConns(5)和SetMaxIdleConns(2) - 不要用
database/sql的全局Open后不设限 —— 租户 A 的慢查询会吃光连接，导致租户 B 直接卡在sql.ErrConnDone - 在
ctx.Locals("tenant_db", db)存进去，后续 handler 用ctx.Locals("tenant_db").(*sql.DB)拿，别再查 map
租户上下文丢失最常发生的三个位置
哪怕前面都做对了，这三个地方一疏忽，租户 ID 就断链，轻则查错数据，重则写入其他租户表。
- Goroutine 内：Fiber 的
Ctx不能跨协程传递，go func() { ... ctx.Locals(...) }会 panic 或读到空值；必须显式传参：go doSomething(tenantID, db) - 第三方异步任务（如 RabbitMQ 消费）：消息体里必须包含
tenant_id字段，消费者启动时重新初始化租户 DB 和缓存 client - 中间件顺序错误：比如
jwt.New()放在租户中间件之后，Token 里有tenant_id却没被提前提取，导致后续逻辑拿不到
真正的难点不在“怎么写路由”，而在于租户上下文是否像氧气一样无处不在又不可见——它要能穿透中间件、DB 层、缓存层、异步任务，且每次切换都干净利落不残留。任何一层靠“约定”而不是“强制绑定”，迟早出事。
