GORM延迟加载非默认行为，需显式启用并确保db会话活跃；未导出字段、Preload覆盖或事务关闭会导致失效，真延迟须手动调用Association API触发查询。
GORM 的延迟加载（Lazy Loading）不是开箱即用的默认行为，它必须显式启用、配合正确结构，并在活跃会话中访问才真正生效。多数“不生效”问题，根源在于 Preload 覆盖、事务提前关闭或结构体字段未导出。
为什么调用 Posts 字段没触发查询？
GORM 默认禁用延迟加载；即使你没写 Preload，也不会自动代理——它直接返回空切片或 nil，而不是代理对象。要启用，必须在初始化时设置：gorm.Config{DisableForeignKeyConstraintWhenMigrating: true, PrepareStmt: true} 不够，关键在 db.Session(&gorm.Session{NewDB: true}) 之外，还需开启 Load 模式：
- 全局启用：创建
*gorm.DB时传入gorm.Config{DryRun: false}无用，真正需要的是gorm.Open(..., &gorm.Config{NowFunc: func() time.Time { return time.Now() }})配合后续手动控制 - 更可靠方式：使用
db.Unscoped().Joins("Posts").First(&user, 1)是预加载，不是延迟；延迟必须靠user.Posts访问触发，且前提是该字段是导出字段 + 关联已声明preload:false - 常见误判：打印
user.Posts看到空切片，就以为“没加载”，其实只是还没触发——只要之后调用len(user.Posts)或遍历，且 db 会话仍活跃，就会发第二条 SQL
preload:false 和 LazyLoad 的区别在哪？
preload:false 只是告诉 GORM “别在主查询里 JOIN 或子查询加载”，但它本身不启用延迟代理；GORM 目前（v1.25+）没有内置的运行时代理机制（如 MyBatis 的 CGLIB），所谓“延迟加载”实际是“延迟执行关联查询”，依赖你在访问字段时手动调用 db.Model(&user).Association("Posts").Find(&posts)。
-
preload:false是映射配置项，影响主 SQL 是否包含关联逻辑 - 真延迟需配合
AssociationAPI：比如db.Model(&user).Association("Posts").Count()才会查数量，.Find()才拉数据，不调就不查 - 没有代理对象：GORM 不生成
Posts字段的动态代理，所以无法像 Hibernate 那样靠 getter 触发——你得自己写那行.Association(...).Find() - 若字段类型是
[]Post且未初始化，直接访问user.Posts得到的是零值，不会 panic，但也不会自动查库
事务关闭后访问 Posts 为何 panic 或返回空？
GORM 的 Association 查询依赖底层 *gorm.DB 实例，而该实例若来自已 commit/rollback 的事务，其连接可能已释放或不可复用。这不是“延迟失效”，而是“连接失效”。
- 典型错误：在
tx := db.Begin()内查出user，然后tx.Commit()，再调tx.Model(&user).Association("Posts").Find()—— 此时tx已不可用 - 正确做法：延迟查询必须复用同一个未关闭的
*gorm.DB，或显式传入新会话：db.Session(&gorm.Session{}).Model(&user).Association("Posts").Find() - 注意
db.Scopes()或中间件可能隐式创建新 session，导致关联查询用错连接 - 日志验证：开启
logger.Default.LogMode(logger.Info)，看第二条 SQL 是否发出；没日志 = 没触发，大概率是调用路径脱离了有效 db 实例
GORM 的“延迟加载”本质是手动延迟执行关联操作，而非自动代理拦截。最容易被忽略的一点：它不改变字段访问语法，但也不提供任何运行时保障——你必须自己确保 db 实例存活、自己补上 .Association().Find() 这一行，否则永远只拿到零值。
