preload必须带条件过滤，否则等于没优化；需用闭包约束字段、状态和数量，禁用association避免隐式n+1，复杂查询优先joins+select，调试必用debug()验证sql条数与索引。
Preload必须带条件过滤，否则等于没优化
很多人以为只要写了 db.Preload("Orders").Find(&users) 就解决了N+1，其实只是把101次查询变成了2次——但第二次查的是全量订单，内存和网络开销可能比N+1还高。
真正有效的预加载要控制字段、条件和数量：
- 用闭包函数对预加载子查询做约束：
db.Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "paid").Select("id, user_id, amount") }) - 避免
Select("*")或不加Select，GORM默认会拉取关联表所有字段 - 高频分页场景下，
Limit在预加载里也得加，比如只取每个用户的最近3笔订单
一对多关联别依赖Association，它就是隐式N+1开关
user.Orders 看似方便，但它是延迟加载代理，第一次访问时才触发SQL。如果在循环或模板里反复读取，就会在不经意间复活N+1。
更危险的是：它无法被 Preload 覆盖——你写了 Preload("Orders")，但代码里又写了 user.Association("Orders").Find(&orders)，GORM会再发一次查询。
- 彻底禁用
Association方法，改用显式预加载或Joins - 模型定义中给关联字段加
gorm:"foreignKey:UserID;constraint:OnUpdate:CASCADE,OnDelete:CASCADE"，确保外键语义清晰 - 如果真需要运行时动态加载，至少用
db.Scopes(WithOrdersPaid).Find(&users)这类自定义Scope封装逻辑
复杂报表类查询直接用Joins+Scan，别硬套Preload
当你要查“用户姓名 + 最近一笔已支付订单金额 + 订单创建时间”，Preload会先查用户、再查所有匹配订单、再在内存里聚合——而 Joins 可以一条SQL搞定，还能走索引。
注意几个关键点：
-
Joins("LEFT JOIN orders ON orders.user_id = users.id")后必须用Select显式指定字段，否则GORM可能拼出冗余列导致扫描变慢 - 别在
Joins后跟Preload，两者混用会让GORM生成嵌套子查询，执行计划不可控 - 如果关联表数据量大，
LEFT JOIN可能因笛卡尔积放大结果集，此时应优先考虑应用层两次查询（主表+IN子句查关联）
Debug模式下必须开日志，否则永远不知道SQL怎么跑的
很多团队上线后才发现N+1，不是因为不会写Preload，而是没验证过实际执行了几条SQL。GORM的 Debug() 是唯一可信的判断依据。
- 开发期强制加：
db.Debug().Preload("Orders").Find(&users)，看终端输出是否只有2条SQL - 注意区分
db.LogMode(true)（旧版）和Debug()（新版），后者才包含参数化值和执行耗时 - 生产环境不能开Debug，但可以用
gorm.Logger实现采样日志，比如只记录 >100ms 的查询
最常被忽略的一点：Preload生成的第二条SQL，它的WHERE条件是否命中索引？哪怕只有一条SQL，没索引照样慢。查完日志，一定去数据库里 EXPLAIN 一下。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
