postgresql schema隔离是go多租户架构中真正可落地、可运维的默认方案；字段级隔离（tenant_id）仅适用于中小saas或租户数少于50且无安全审计要求的场景。
租户ID怎么注入到数据库查询链路里
不能靠全局变量或 context.WithValue 临时塞，一不小心就漏传。核心是把租户标识作为请求上下文的必传字段，在 HTTP 中间件里从 header 或 token 解析 tenant_id，然后透传到 DAO 层。
推荐做法：用自定义 context.Context 键（比如 ctxTenantKey）存取，避免和标准库 key 冲突；所有 DB 查询必须显式携带该 context，否则 panic —— 可在 ORM 初始化时加校验钩子。
- HTTP 入口统一从
X-Tenant-IDheader 读取，缺失则返回400 Bad Request - SQL 查询前检查 context 是否含有效
tenant_id，没通过直接 return error - 不要在 model struct 里加
TenantID uint64字段自动填充，容易被绕过
GIN + GORM 怎么做自动 tenant 过滤
GORM 的 Scope 是最稳妥的方式，它能确保所有查询（包括关联、Preload、Count）都带上 WHERE tenant_id = ? 条件，且不会被开发者手动 skip。
注意：不能只靠 DefaultScope，因为 GORM v2+ 已废弃该机制；要用 WithContext() + 自定义 Scope 函数。
- 定义
tenantScope函数，从 context 提取tenant_id并调用db.Where("tenant_id = ?", tid) - 每个 DAO 方法都显式调用
db.Scopes(tenantScope).Find(&list) - 写操作（Create/Update/Delete）同样要套 Scope，否则可能跨租户覆盖数据
- 慎用
Unscoped()—— 真需要绕过隔离时，必须走单独 audit 日志并二次鉴权
PostgreSQL schema 隔离 vs 单表 tenant_id 字段，怎么选
schema 隔离适合强合规场景（如金融），但运维成本高：建库/删租户要 DBA 权限，连接池需按 schema 分组，ORM 无法自动切换 schema；单表字段更轻量，但全量 SQL 必须带过滤条件，漏一条就出事。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
实际项目中，90% 场景用单表 + 强 Scope 控制更可控。schema 方案只在租户间数据敏感度极高、且有专职 DBA 支持时才值得上。
- 单表方案：索引必须包含
(tenant_id, xxx)，否则查询性能暴跌 - schema 方案：GORM 不原生支持动态 schema 切换，得自己拼
db.Table("public.users")→db.Table("tenant_123.users") - 混合方案（如大租户独立 schema + 小租户共享表）会显著增加路由逻辑复杂度，不建议初期采用
如何防止租户ID被伪造或越权访问
租户 ID 本身不是认证凭据，只是隔离维度。真正关键的是：谁有权访问哪个 tenant_id，必须由鉴权服务（如 OPA 或自研 RBAC）在中间件里校验，不能只信 header。
常见漏洞是「前端传啥后端就用啥」，比如用户 A 登录后，篡改 X-Tenant-ID: 999 尝试访问租户 999 的数据 —— 这种请求必须在鉴权层就被拦截。
- 鉴权中间件查用户 token 绑定的租户白名单，
tenant_id不在列表内直接403 Forbidden - DAO 层不负责鉴权，只负责强制隔离；哪怕鉴权出错，DB 层也应拦住非法 tenant_id 查询
- 日志里记录每次请求的
user_id、tenant_id、操作类型，便于审计溯源
最麻烦的不是技术实现，而是租户上下文在 goroutine 泄露 —— 比如异步任务、定时器、goroutine pool 里忘了传 context，导致 tenant_id 丢失或错乱。这种 bug 很难复现，上线后才暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
