GORM本身不支持按模块限制连接配额，因其底层*sql.DB连接池全局共享、不可分割；所有模块共用同一池，无隔离层或路由机制；可行替代方案是应用层加信号量限流或采用分库/分实例物理隔离。
GORM 本身不支持按模块限制连接配额。它底层用的是 Go 标准库 *sql.DB，而 *sql.DB 的连接池是全局共享、不可分割的——你无法让“用户模块”最多用 5 个连接、“订单模块”最多用 10 个，GORM 没提供这种切片式配额控制。
为什么不能直接按模块设连接上限
连接池不是“资源桶”，而是带复用逻辑的句柄集合。GORM 的 *gorm.DB 实例背后只有一个 *sql.DB，所有模块调用 db.First、db.Create 等方法时，都从同一个池里取连接。没有模块隔离层，也没有运行时路由标签或租户上下文透传机制来区分请求来源。
常见误操作包括：
- 给每个模块 new 一个
*gorm.DB（错：会创建多个独立池，导致数据库总连接数爆炸） - 在中间件里动态调
db.DB().SetMaxOpenConns（错：这是全局生效，且反复调用会覆盖前值） - 用 context.WithValue 传“模块名”再做拦截（错：GORM 不解析 context 中的模块标识，也无法据此限流）
实际可行的替代方案：连接池 + 外部信号量
若真需约束某模块（如报表导出）不抢走核心接口的连接，得靠应用层加一道闸门，而不是改 GORM 配置：
- 为高开销模块单独定义一个
semaphore（例如用golang.org/x/sync/semaphore），设最大权值为 3 - 每次执行该模块的 DB 操作前，先
sem.Acquire(ctx, 1)；完成后sem.Release(1) - 这个信号量和连接池解耦：它不控制连接数，但能限制并发请求数，间接降低该模块对池的竞争压力
- 注意：信号量要按业务粒度设计，比如“单次导出任务”占 1 权值，而不是“每条 SQL”占 1 权值（否则开销过大）
更合理的做法：分库或分实例隔离
真正需要模块级连接隔离的场景，说明负载特征已差异巨大。这时应跳出“在一个 DB 实例上切配额”的思路：
- 把报表、统计等低优先级查询，指向只读从库（独立
*sql.DB实例），主库留给交易链路 - 将后台管理模块连到专用 PostgreSQL 实例，与前台服务物理隔离
- 用数据库代理（如 ProxySQL、MySQL Router）做连接层路由，按 SQL 注释（如
/* module=report */）分流，但这要求驱动支持注释透传且代理开启解析
这类方案成本更高，但稳定性和可观测性远优于在单池内硬塞配额逻辑。
最常被忽略的一点：所谓“模块连接争抢”，80% 源于慢查询没加索引或未加 limit，而非池配置本身。先查 SHOW PROCESSLIST 或数据库慢日志，比急着加信号量更有用。
