iris.Host()仅匹配Host头，不自动绑定租户上下文或提供数据隔离，需配合中间件提取tenantID并注入ctx.Values()，再贯穿至DB、缓存、日志等各层，否则易致数据混用或越权。
为什么不能只靠 iris.Host() 做租户路由
iris.Host() 本身只是个匹配 Host 头的路由分组工具，它不自动绑定租户上下文，也不提供租户隔离的数据作用域。直接用它注册 handler，所有租户共享同一套响应逻辑和变量作用域，容易导致数据混用或权限越界。真实场景中，你还需要在请求生命周期内提取租户标识、加载对应配置、切换数据库连接或限流策略——这些都得手动注入。
常见错误现象：ctx.Request().Host 拿到的是带端口的字符串（如 tenant-a.example.com:8080），没做标准化就用于查租户表，结果查不到；或者多个子域名共用同一 handler，但 handler 里没做 tenantID 校验，导致 A 租户能访问 B 租户的 /api/orders。
用 iris.Host() + 中间件提取租户 ID
核心思路是：先用 iris.Host() 分流到统一入口，再通过中间件解析 Host、校验租户合法性，并把 tenantID 注入 ctx.Values()。
实操建议：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- Host 路由必须覆盖所有合法租户域名，推荐用通配符模式：
app.Host("*.example.com")，避免漏掉新租户子域 - 中间件中用
strings.TrimSuffix(ctx.Request().Host, ":8080")或net.ParseIP()前先清理端口，再取一级子域（如tenant-a） - 租户 ID 必须经过白名单校验（查缓存或 DB），失败时立即返回
404或403，不要 fallback 到默认租户 - 把
tenantID存进ctx.Values().Set("tenant_id", id)，后续 handler 和数据库中间件都从中读取
如何让每个租户走独立的数据库连接池
Iris 本身不管理数据库连接池生命周期，所以不能靠全局sql.DB。你需要按租户动态获取连接池实例。
关键点：
- 连接池应按
tenantID缓存（例如用sync.Map），首次访问时根据租户配置初始化，避免每次请求都新建 - 租户配置（如 DSN）不能硬编码，建议从外部配置中心或数据库
tenants表加载，并支持热更新 - 在 handler 中调用
getDB(tenantID)获取连接池，而不是用全局变量db - 注意连接池最大空闲数和最大打开数要按租户数做总量控制，否则可能耗尽系统文件描述符
路由冲突：当 Host 路由和普通路由共存时优先级怎么定
Iris 的路由匹配顺序是：Host 分组 > HTTP 方法 > 路径字面量 > 参数路径 > 通配符。但如果你同时注册了app.Get("/health") 和 hostApp.Get("/health")，前者会覆盖后者——因为 Host 分组是子路由器，它的路由不会自动“屏蔽”父路由。
容易踩的坑：
- 不要在主
app上注册任何与租户相关的通用路径（如/api/users），否则它会劫持所有 Host 请求 - 所有租户专属路由必须严格定义在
iris.Host()返回的子应用上，主应用只留跨租户公共接口（如/login、/signup） - 如果需要 fallback 行为（比如某个租户域名未注册），得显式加一个兜底 Host 分组：
app.Host("*")，并在其 handler 中返回404
tenantID。漏掉任意一环，隔离性就破了。 
