go中路由与数据库必须正交分离，db选择应在handler执行前完成；需按租户预加载独立*sql.db实例并用sync.map缓存，入口中间件解析租户标识注入context，handler显式取值，读写分离由业务代码严格控制。

Go 里没有“路由切换数据库”这回事——路由和数据库是两个正交层，强行绑定会把租户隔离、读写分离、多主分库等需求全搞混。 真实场景下，数据库连接选择必须发生在 handler 执行前（甚至 SQL 执行前），靠 HTTP 路径前缀或 method 去“路由数据库”属于设计倒置，容易导致事务跨库、连接池争抢、缓存穿透等问题。

为什么不能用 Gin 的 Group 或 mux 的 Subrouter 控制数据库

Group 和 Subrouter 只影响 req.URL.Path 匹配和中间件注入时机，不触达数据库连接逻辑。常见错误包括：

• 在 v1 := r.Group("/api/v1") 里注册的 handler 仍用全局 db *sql.DB，结果所有租户查的都是同一个库
• 误以为 r.HandleFunc("/user/{id}", h).Methods("GET") 能自动挑 PostgreSQL 实例，其实它只提取 id 字符串，不参与 DB 选择
• 把 tenantID 放 URL 路径（如 /t/abc123/users）后，在 middleware 里解析并塞进 context，但 handler 忘了从 ctx.Value(tenantDBKey) 拿实例，继续用错库

正确做法：DB 实例按租户/环境/角色预加载到 sync.Map

租户标识（如 X-Tenant-ID、Host、JWT 中的 sub）应在入口中间件中校验并映射到具体 *sql.DB，再注入 context。关键点：

Skill Weave Chains — 技能链路由引擎

开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。

下载

• 每个租户对应独立 *sql.DB 实例，各自调用 SetMaxOpenConns、SetConnMaxLifetime，避免流量倾斜拖垮其他租户
• 用 sync.Map 缓存映射关系：tenantDBs.LoadOrStore(tenantID, newDB(cfg))，避免每次请求都重连
• handler 中必须显式取值：db := ctx.Value(tenantDBKey).(*sql.DB)，不能 fallback 到全局变量
• 若租户配置变更（如 DB 地址更新），需触发 sync.Map 的 LoadAndDelete + 重建，而非热 reload 连接池

读写分离必须由业务代码控制，不是 ORM 自动识别

Go 标准库和主流 ORM（如 GORM）都不支持“写用主库、读自动切从库”的声明式语法。你得自己拆开：

• 写操作（INSERT/UPDATE/DELETE）必须用主库实例：masterDB.ExecContext(ctx, ...)
• 读操作（SELECT）可走从库，但要确保事务内不混用：tx, _ := masterDB.BeginTx(ctx, nil); tx.QueryRow(...) —— 此时必须用 tx，不能换从库
• 不要依赖 db.Rebind() 或 gorm.Session(&gorm.Session{Write: true}) 这类模糊开关，它们在跨库场景下行为不可控
• 如果用了 GORM，每个库必须是独立 *gorm.DB 实例：gorm.Open(mysql.Open(dsn), &gorm.Config{})，别试图复用 gorm.DB 的 callback 链去“动态切库”

容易被忽略的三个硬伤

多数人卡在细节上：一是 sql.Open 不真正建连，漏掉 db.Ping() 导致启动时无法发现 DSN 错误；二是用 func init() 初始化 DB，panic 后无堆栈、难定位；三是把 *sql.DB 当成单例塞进全局 var，多个租户共用一个连接池，查库混乱还连不上报错全是 connection refused 而非明确的租户 ID。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！