租户识别应通过域名/子域名解析并校验元数据，禁止硬编码或不可信header；PostgreSQL需用SET search_path配合连接生命周期控制，禁用拼接表名；GORM须每请求显式指定schema表名。
Go 多租户 Web 请求如何识别租户 ID
租户识别不是靠猜，而是靠请求上下文里明确、可验证的来源。常见错误是把 tenant_id 硬编码进 URL 路径（如 /t/abc123/users）却不校验权限，或依赖不可信的 header（如自定义 X-Tenant-ID）且没做中间件拦截。
推荐做法是统一走「域名」或「子域名」识别，配合中间件提取并注入到 context.Context：
- 用
http.Request.Host解析子域名（如acme.example.com→acme），比路径参数更难伪造 - 必须查一次租户元数据表（比如
tenants表），确认该租户存在且状态为active，不能只缓存不校验 - 校验失败直接返回
404或403，不要 fallback 到默认租户 - 提取后的
tenantID用context.WithValue注入，后续 handler 和 DB 层都从ctx里取，别传参、别用全局变量
PostgreSQL 中如何安全切换 schema
PostgreSQL 的 SET search_path 是最轻量的 schema 隔离方式，但直接在连接上执行它极危险：连接复用时可能残留前一个租户的 schema，导致数据错读。常见错误是用 db.Exec("SET search_path TO tenant_abc") 后就复用连接。
正确做法是让每个租户请求独占一个逻辑连接上下文：
立即学习“go语言免费学习笔记（深入）”；
- 使用
sql.Tx或pgx.Conn（非pgxpool.Pool）显式控制生命周期，在事务开始时调用conn.Exec("SET search_path TO $1", tenantSchema) - 如果必须用连接池（如
pgxpool.Pool），改用pgxpool.Conn的ExecEx方法，传入pgx.QueryExecModeSimpleProtocol并带上search_path参数，避免污染连接状态 - schema 名必须白名单校验（正则
^[a-z][a-z0-9_]{2,30}$），禁止拼接用户输入；tenant_123; DROP TABLE users这类注入会直接崩库 - 所有 DDL（如建表）必须在固定
publicschema 下执行，租户 schema 只放 DML 数据表
为什么不能用 Go 的 database/sql + 拼接表名实现多租户
用 "SELECT * FROM " + tenantID + "_users" 这种方式看似简单，实则埋了三颗雷：SQL 注入、连接池污染、ORM 兼容性断裂。
典型问题包括：
-
tenantID若来自请求且未过滤，tenant_abc; DROP TABLE orders就能跑通 - 不同租户查询混用同一个
*sql.DB，prepare statement 缓存会冲突（tenant_abc_users和tenant_xyz_users被当成同一张表） -
gorm / sqlx 等 ORM 无法感知动态表名，预编译失效，
Scan映射失败，日志里全是sql: expected 3 destination arguments in Scan, not 2 - PostgreSQL 表名长度限制 63 字节，
tenant_longname_with_suffix_users容易超限，报错identifier_length_exceeded
GORM v2 如何适配 schema 切换而不改模型定义
GORM 自带 Session 机制可以隔离 schema，但很多人误以为设置一次 Config.NamingStrategy 就能全局生效——其实它只影响建表和默认表名生成，不参与运行时查询。
真正可用的方式是：
- 初始化时禁用自动表名前缀：
gorm.Config{NamingStrategy: schema.NamingStrategy{NoLowerCase: true}}，避免 GORM 把User自动转成users - 每个请求用
db.Session(&gorm.Session{Context: ctx}).Table(tenantSchema + ".users")显式指定表（注意带 schema 前缀） - 若用
Preload关联查询，必须对每个关联字段单独Session+Table，GORM 不会自动继承主表 schema - 慎用
db.Unscoped()，它会绕过Table设置，直接查users，导致跨租户泄露
schema 切换本身不难，难的是所有 DB 操作路径都得被租户上下文穿透——从中间件、到事务、再到每一条 query，漏掉任意一环，隔离就形同虚设。
