go模块依赖无法承载租户配置，因为go.mod仅管理代码复用与版本对齐，import路径不感知租户id，全局变量或单例对象会导致多租户间配置覆盖与竞态，所有租户共享同一二进制，租户隔离必须由业务层显式设计并贯穿dao、缓存、连接池、配置中心等每一环节。
Go 模块依赖本身不解决多租户配置共享问题；配置共享必须由业务层显式设计，不能靠 go.mod 或 import 路径隐式传递租户上下文。
为什么 go.mod 和 import 路径无法承载租户配置
Go 的模块系统只管理代码复用和版本对齐，go.mod 中的 require 声明不携带运行时状态，import 路径（如 "github.com/myorg/core"）也不感知租户 ID。所有租户共用同一份编译后的二进制，若在包级变量里存租户配置（如 var TenantConfig = map[string]string{}），就会互相覆盖或竞态读写。
- 全局变量或 init 函数初始化的配置，在多租户场景下是“单例陷阱”——它属于整个进程，不是每个租户的专属副本
- 依赖注入框架（如 wire）默认生成单例对象，若未按 tenantID 分 key 构造 provider，实例就会被多个租户复用
- 子模块（如
core/auth）若直接 importconfig包并调用GetDBDSN()，而该函数返回的是静态字符串，就完全丢失租户维度
GORM 查询中 tenant_id 怎么避免被模块依赖绕过
常见错误是把租户过滤逻辑藏在某个“基础模块”里，以为只要其他模块 import 它就自动生效。但 GORM 的 Preload、Count、Raw、Joins 都不继承上层 scope，模块间调用也无法自动透传 tenantID。
- 禁用裸
db.Where().Find()：必须统一走封装函数，例如userRepo.FindByID(ctx, tenantID, id)，tenantID是参数，不是从ctx.Value取 - Scopes 不能跨模块隐式生效：即使
core/db定义了TenantScope(tenantID)，orderRepo.ListByStatus()若没显式调用它，就等于没隔离 - 关联查询（如
Preload("Orders")）必须在Order的 DAO 层也接收tenantID并加 WHERE，否则查出的是全库订单 - 软删除字段（
deleted_at）要和tenant_id同级约束：Where("tenant_id = ? AND deleted_at IS NULL", tenantID)，不能只依赖 GORM 的SoftDelete插件
配置中心客户端怎么做到租户间物理隔离
viper 是全局单例，etcd clientv3.Client 线程安全但不 tenant-aware；共享 client + 共享 watch channel 是跨租户配置污染的根源。
- 不要复用同一个
clientv3.Client实例做多租户 watch：哪怕 prefix 不同（如/tenant/a/configvs/tenant/b/config），watch goroutine 若共用一个回调函数，就可能把 a 的变更误推给 b - 每个租户必须有独立的
TenantConfigClient实例，内嵌*clientv3.Client和tenant string，所有方法（Get、Watch）自动拼前缀 - 缓存不能用全局 map 存快照：应为每个租户维护独立内存缓存（如
ristretto.Cache实例），key 必须含tenantID，例如tenant:a:feature_flag:paywall - 热更新时，watch goroutine 必须绑定租户生命周期：租户下线时，主动 cancel 对应 ctx，关闭 watcher，清空本地缓存
连接池缓存为什么必须用 sync.Map 而非全局 map
数据库连接池是多租户最易被忽略的性能与安全瓶颈。用普通 map[string]*sql.DB 会引发并发 panic，而用全局变量或 context 透传又破坏封装性。
-
sync.Map是唯一适合高并发租户路由的结构：它无锁读、分段写，支持LoadOrStore原子初始化，避免重复建连 - 每次调用
sql.Open初始化新连接后，必须立刻执行db.Exec("SET search_path TO " + tenantID)，且设置db.SetMaxOpenConns(5)和db.SetConnMaxLifetime(5 * time.Minute)，否则连接数爆炸 - 切忌手写表名拼接（如
"tenant_" + tenantID + ".users"）：这会让 GORM 的钩子（BeforeCreate）、事务、测试全部失效 - PostgreSQL 的
search_path是 session 级，所以必须为每个租户维护独立*sql.DB实例；MySQL 不支持该机制，只能分库，但连接池无法复用，1000 租户 ≈ 1000 个*sql.DB
真正难的不是写十个 tenantID 参数，而是让每个 DAO 方法、每条 Raw SQL、每次 Preload、每个 Watch 回调、每个缓存 key 都强制带上它——漏一处，就是 P0 数据泄露。模块依赖只是代码组织方式，它不自动带来租户安全，那得靠每一行手动校验和结构化约束来兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
