preload不加条件会导致全表扫描和n+1退化，必须用函数式预加载并显式指定where、select（含外键/主键）、嵌套层级控制及字段名严格匹配。
Preload字段不加条件就等于全表扫描
Preload("Orders")看着省事，但GORM会为每个主记录生成一个IN查询，比如SELECT * FROM orders WHERE user_id IN (1,2,3,...100)。如果没加WHERE过滤，哪怕只查10个用户，也会把整个orders表符合条件的记录全拉下来——字段越多、关联越深，内存和网络开销越爆炸。
实操建议：
- 必须用函数式条件预加载：
Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "paid").Select("id, user_id, amount, created_at") }) -
Select()里至少包含外键（如user_id）或主键，否则GORM无法绑定到主结构体，user.Orders仍为空切片 - 嵌套三层以上（如
Preload("Orders.Items.Product")）优先改用Joins()手动JOIN，避免IN列表膨胀和反射失败
嵌套Preload字段名错一个字母就静默失效
GORM对Preload字段名是严格字符串匹配，不自动推导、不报错、不提示。写成Preload("orders")（小写）、Preload("Order")（单数）或Preload("UserOrders")（结构体名≠关联字段名），都会导致关联查询完全不触发，users[0].Orders始终是空切片，日志里也看不到第二条SQL。
实操建议：
- 字段名必须与结构体中定义的**首字母大写字段名完全一致**，包括大小写和复数形式
- 多对多中间表必须显式定义结构体，且所有字段导出（首字母大写）并加
gorm:"column:xxx"标签 - 调试时务必加
db.Debug()，确认是否生成了类似SELECT * FROM order_items WHERE order_id IN (?)的语句
游标分页比OFFSET更稳，但字段选错就漏数据
Offset(100000).Limit(20)在MySQL里不是跳指针，而是真实扫描前100020行再丢掉前100000条；并发写入时，新插入记录可能让下一页重复或跳过。游标分页能解决这个问题，但前提是游标字段必须单调递增且无重复——用created_at要注意精度，DATETIME默认秒级，同一秒插入多条就会乱序。
实操建议：
- 首选自增
id字段做游标：WHERE id > ? ORDER BY id ASC LIMIT 20 - 若必须用时间字段，数据库列类型设为
DATETIME(3)或BIGINT时间戳，Go端用time.UnixMilli() - 游标查询不能混用
ORDER BY created_at DESC和id > ?，方向必须一致，否则索引失效
连接池没调好，再快的SQL也卡在等待上
GORM本身不管理连接池，它只是database/sql的包装层。默认SetMaxOpenConns(0)等于不限制，MySQL服务端扛不住；SetMaxIdleConns(2)导致每次并发都新建连接；SetConnMaxLifetime(0)让MySQL主动断连后GORM不断重连，引发风暴。
实操建议：
- 在
gorm.Open()后立刻拿到原生连接池：sqlDB, _ := db.DB() -
SetMaxOpenConns()设为峰值QPS × 平均耗时（秒） + 20%缓冲，一般100够用 -
SetMaxIdleConns()设为SetMaxOpenConns()的1/2～2/3，避免频繁建连销毁 - 加
db.Ping()校验初始化是否成功，别等第一个请求才暴露问题
复杂点在于：Preload的条件、字段、顺序、结构体标签，四个地方错一个，查询就静默退化成N+1；而连接池参数不调，高并发下所有优化都白搭——这两件事必须在第一个查询上线前就做完。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
