PostgreSQL schema隔离需缓存租户专属*sql.DB并设search_path，字段隔离必须强制注入tenant_id到每条SQL且禁用可绕过逻辑；Echo中tenant_id须从JWT或子域名可信源提取并校验，禁止依赖不可信输入。
直接用 Echo 做多租户，别指望中间件塞个 tenant_id 就完事——漏一次查询条件或绕过一次 Preload，数据就跨租户裸奔。真正能兜底的只有两种路径：PostgreSQL schema 隔离（需缓存租户专属 *sql.DB），或字段隔离（必须强制注入 WHERE tenant_id = ? 到每条 SQL，且禁用所有可绕过逻辑）。
如何在 Echo 中安全提取并绑定 tenant_id
靠 X-Tenant-ID header 或 query 参数是高危起点，它等于把租户边界交给不可信输入。Echo 的中间件里必须从可信源推导：
• JWT 签名校验通过后，从 payload 显式取 tenant_id 字段，并校验该租户是否在用户授权列表中（不能只解码不查库）
• 若走子域名（如 tenant-a.example.com），必须白名单校验 Host 头，防伪造域名注入
• 提取后立刻用 c.Set("tenant_id", tid) 存入 Echo Context，禁止用全局变量、闭包捕获或 context.WithValue() —— 类型断言失败会 panic，异步任务中还可能丢失
• 后续所有 handler 必须从 c.Get("tenant_id") 取值，且做非空和类型检查，别直接强转
GORM 在 Echo 中怎么避免 Preload / Count 绕过 tenant_id
Preload("Orders") 和 Count() 默认完全不感知租户上下文，哪怕主查询加了 Where("tenant_id = ?", tid)，关联查询和聚合仍扫全表。
• 禁止裸调 db.Preload("Orders").Find(&u)；改用封装方法，如 tenantDB.User().WithOrders(tid).Find(&u)，内部对 Orders 关联也手动加 WHERE tenant_id = ?
• Count() 必须显式带租户条件：db.Where("tenant_id = ? AND status = ?", tid, "pending").Model(&Order{}).Count(&count)，不能依赖 Scopes 透传
• Unscoped() 是最大陷阱：软删除字段 deleted_at 必须和 tenant_id 同级约束，写成 Where("tenant_id = ? AND deleted_at IS NULL", tid)，否则 Unscoped().Where("id = ?", x) 直接越权
• 所有 DAO 方法签名必须显式接收 tenantID string，禁止从 context.Value() 或 c.Get() 动态取 —— 这是为防止异步任务或嵌套调用时传错/丢值
PostgreSQL schema 隔离下 Echo 怎么复用连接池
在 Echo handler 里执行 db.Exec("SET search_path TO tenant_abc") 是无效的，因为 *sql.DB 连接池不保证复用同一物理连接，session 级命令无法跨请求生效。
• 正确做法是用 sync.Map 缓存租户专属 *sql.DB 实例：tenantDBs.LoadOrStore(tenantID, newTenantDB(tenantID))
• newTenantDB() 内部用标准 DSN 打开连接，立刻执行 db.Exec("SET search_path TO " + tenantID)，后续所有 Query/Exec 自动落在该 schema
• 必须调 db.SetMaxOpenConns(5) 和 db.SetConnMaxLifetime(5 * time.Minute)，否则 1000 租户 × 默认 100 连接 = PostgreSQL 直接被打崩
• 切忌手写表名拼接（如 "tenant_abc.users"）——破坏 ORM 抽象、GORM 钩子（如 BeforeCreate）全部失效，SET search_path 才是轻量且兼容所有驱动的方式
Redis 缓存键为什么必须带 tenant_id
缓存键漏掉 tenant_id 是线上 P0 故障高频点，不是并发问题，是设计缺陷。A 租户更新 config 后写入 user:123，B 租户读同一 key 就拿到脏数据。
• 所有 Redis 键必须形如 tenant:{tenant_id}:user:{id} 或 tenant:{tenant_id}:config:main
• 更进一步，可将租户 ID 映射为 Redis 数据库编号（如 SELECT 10 对应租户 abc123），但需确保客户端连接池支持动态 SELECT
• 缓存 miss 时，务必把带 tenant_id 的结果回填，别让 redis.Get(key).Nil() 后直接查 DB 却不写回 —— 下个租户命中就是错乱数据
• 使用 redis-go 时，注意 Get 返回 nil 不代表 key 不存在，要检查 err == redis.Nil，否则误判导致重复查库
最易被忽略的是：GORM 的 Raw()、Joins()、FirstOrInit() 全部绕过 Scopes；MySQL 没有 search_path，硬上 schema 隔离等于自废武功；而字段隔离下，每张表的 tenant_id 字段没建联合索引（如 (tenant_id, created_at)），分页查询就会慢成秒级延迟。
