真正可靠的多租户方案只有两种：字段隔离必须强制参数化（DAO方法显式传tenantID），schema隔离必须一租户一*sql.DB实例（用sync.Map缓存映射）；其他折中方案均在压测或审计中暴雷。
GoLand 本身不提供多租户能力，它只是帮你写对代码的工具；真正决定租户是否隔离的，是你的 DAO 层函数签名、SQL 构造逻辑、连接池管理方式——这些地方写错一处，GoLand 再智能也拦不住跨租户数据泄露。
DAO 方法必须显式接收 tenantID 参数，禁用 context.Value
GoLand 的代码补全和类型检查对 context.Value 几乎无效：断言失败不报错、异步任务里值为空、单元测试 mock 错了也跑不出问题。线上一出事就是 P0 数据泄露。
-
func (r *ReportRepo) GetByDate(ctx context.Context, tenantID string, date time.Time) (*Report, error)——tenantID必须是第一等参数，IDE 能校验、测试能传、压测能覆盖 - 禁止写
tenantID := ctx.Value("tenant_id").(string)，哪怕只在中间件里塞了一次，下游任意一层漏传或复用旧ctx就失效 - GORM 的
Count()、Preload()、Raw()全部绕过 Scopes，不显式传tenantID就等于裸查全库
PostgreSQL schema 隔离必须用 sync.Map 缓存租户专属 *sql.DB
别在 GoLand 里调试时看到 db.Exec("SET search_path TO tenant_abc") 成功就以为搞定了——连接归还池后 session 状态丢失，下一次 Query 极大概率回到 public schema。
- 用
sync.Map存tenantID → *sql.DB映射，首次访问时初始化：db, _ := sql.Open("pgx", dsn); db.Exec("SET search_path TO " + safeTenantSchemaName) - 必须调
db.SetMaxOpenConns(5)和db.SetConnMaxLifetime(5 * time.Minute)，否则 1000 租户 × 默认 100 连接 = PostgreSQL 拒绝新连接 - 手写
"tenant_abc.users"拼表名会破坏 GORM 的BeforeCreate、事务回滚、迁移脚本，GoLand 里的重构功能也完全失效
缓存 key 必须硬编码 tenant: 前缀，不能依赖 struct hash
Redis 里存 config 这个 key，两个租户先后请求，结果后者命中前者缓存——这不是并发 bug，是 key 设计缺陷，GoLand 的代码检查根本发现不了。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 正确格式：
"tenant:" + tenantID + ":config"或"tenant:" + tenantID + ":user:" + userID，字符串拼接比fmt.Sprintf更可控 -
redis-go的Get()返回nil时，必须把带tenantID的查询结果回填，否则下一个租户直接读到脏数据 - 别用
json.Marshal(struct{TenantID, Key string})生成 key——字段顺序、tag 差异、空字段处理都会导致键不一致
JWT 解析必须在认证层完成，HTTP header 不可信
GoLand 里加个 X-Tenant-ID middleware 看着简洁，但只要前端改个 header 就越权读取他人数据。租户边界只能从已验证的登录态里推导。
- 用户登录后，JWT payload 中存
tenant_id和tenant_role，签名校验通过才解出，别在 middleware 里重新解析或转换 - 用
gin.Context.Set("tenant_id", tenantID)或context.WithValue只是临时传递，关键还是 DAO 层必须显式接收该值 - 异步任务（如消息队列消费者）无法继承 HTTP context，
tenantID必须随消息体透传，不能靠“当时应该有”这种假设
最易被忽略的是 Preload 和 Count 的租户过滤——它们默认不继承主查询的 Scopes，GORM 文档里没写清楚，GoLand 也不会标红，但线上一跑就是全量数据泄露。
