不能靠 Cookie 自身做租户隔离，因其可被前端篡改、导致跨租户登录态污染、无法被反向代理解析，且违反 OAuth2/JWT 最佳实践；应通过子域名或路径前缀由网关注入 X-Tenant-ID 请求头，在中间件中校验并注入上下文。
不能靠 Cookie 自身做租户隔离，必须剥离租户标识并转由服务端可控机制承载。
为什么直接用 Cookie 做租户隔离会失败
Cookie 是浏览器自动携带的、不可靠的客户端状态载体。多租户系统中若把 X-Tenant-ID 或租户域名等关键标识塞进 Cookie，会导致几个硬伤：
- 前端可篡改（比如手动修改
tenant_id=abc为tenant_id=def） - 跨租户登录态污染（用户 A 登录租户 X 后，又访问租户 Y，若 Cookie 未清理或域配置宽松，可能误带租户 X 的凭据）
- 无法配合反向代理/CDN 做路由分发（比如 Nginx 根据 Host 或路径转发，但不解析 Cookie 内容）
- 违反 OAuth2 / JWT 最佳实践：租户上下文应属于授权决策输入，而非认证凭据本身
推荐做法：用请求头 + 中间件提取租户 ID，彻底绕过 Cookie
在 Echo 中，租户识别应发生在请求进入第一层中间件时，且全程不依赖 Cookie：
- 强制所有租户入口使用唯一子域名（如
tenant-a.example.com）或路径前缀（如/t/tenant-a/api/...），由 Nginx 或 Cloudflare 提取后注入X-Tenant-ID请求头 - 编写
tenantMiddleware中间件，从c.Request().Header.Get("X-Tenant-ID")读取，并校验是否在白名单内 - 校验通过后，将租户 ID 存入
c.Set("tenant_id", tenantID)，后续 Handler 可安全调用c.Get("tenant_id") - 绝对不要在中间件里读
c.Cookie("tenant_id")—— 即使你写了http.SetCookie，也只用于 UI 层提示，不参与鉴权链路
如果必须保留租户相关的 Cookie，只允许它做“无害缓存”
某些场景下（如前端多租户切换按钮记忆），需要让浏览器记住上次选的租户，但该 Cookie 必须满足：
- Domain 显式设为一级域名（
Domain=example.com），避免子域名间共享 - Path 设为
/，但 Max-Age ≤ 5 分钟，且每次 HTTP 请求都需重新校验并覆盖 - 名称用
__tenant_hint这类非敏感名，值仅为提示用途（如"tenant-a"），绝不用于构造数据库查询或策略 key - 后端中间件拿到
__tenant_hint后，必须查一次租户注册中心（如 Redis 或 DB），确认该租户真实存在且当前可用，再决定是否采纳
真正危险的不是 Cookie 本身，而是把租户边界交由不可控的客户端状态来定义。只要租户 ID 的首次提取和校验脱离了 Cookie，后续所有缓存、日志、DB 查询、Casbin 策略匹配，才能建立在可信上下文之上。
