gorm本身不阻塞并发，但默认配置和常见写法会导致高并发查询卡死在连接池、n+1或全表扫描上；真正决定并发效率的是db.db()连接池参数、preload是否带条件、查询是否强制limit/order。
直接说结论：GORM本身不阻塞并发，但默认配置和常见写法会让高并发查询迅速卡死在连接池、N+1或全表扫描上——真正决定并发效率的，是db.DB()的连接池参数、Preload是否带条件、以及查询是否强制Limit和Order。
为什么并发一上去就报“too many connections”
这不是GORM的问题，而是*sql.DB连接池没调好。GORM只是包装层，底层复用database/sql的连接管理逻辑。默认SetMaxOpenConns(0)等于不限制，MySQL服务端扛不住；SetMaxIdleConns(2)又太小，频繁建连销毁开销大。
- 必须在
gorm.Open之后立刻拿到原生*sql.DB：用db.DB() - 设
SetMaxOpenConns(100)（按峰值QPS × 平均耗时 / 1000 + 20%缓冲估算） - 设
SetMaxIdleConns(20)，避免空闲连接过少导致重复建连 - 设
SetConnMaxLifetime(time.Hour)，防止MySQL主动断连引发重连风暴
GORM并发查列表时怎么避免N+1和全表扫描
并发查100个用户，再循环查每个用户的订单，不是慢在并发，是慢在101次独立SQL。GORM不会自动合并，它只忠实地执行你写的每一行。
- 禁用裸
Find(&users)：必须加Where和Limit，例如db.Where("status = ?", "active").Limit(50).Find(&users) -
Preload要带过滤：否则Preload("Orders")会把每个用户的全部订单都拉下来，内存爆炸 - 正确写法：
db.Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "paid").Select("id, user_id, amount") }).Find(&users) - 更狠的优化：用
Joins+Scan替代嵌套结构体，字段粒度可控，无反射开销
游标分页在并发场景下为什么比Offset更稳
因为OFFSET在MySQL里是真实跳过前N行，不是指针偏移。并发写入时，第5000页可能扫几万行才凑够20条，锁住连接池，还容易漏数据。
- 必须用单调字段做游标，首选
id（自增主键），次选created_at DESC, id DESC - 首次请求：
db.Order("id ASC").Limit(20).Find(&users) - 后续请求：
db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&users) - 前端传来的
last_id必须校验类型和范围，非法值直接400，别默默转成0或忽略 - 注意：游标分页不能直接
Count总数，要单独走db.Model(&User{}).Where(...).Count(&total)
最易被忽略的一点：所有并发查询语句，只要涉及关联或排序，对应字段必须有数据库索引。没有WHERE status的索引，Limit再早加也没用；没有ORDER BY id的索引，游标分页照样慢成狗。索引不是锦上添花，是并发查询的地基。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
