GORM 不支持开箱即用的延迟加载，因其无运行时代理机制，所谓“延迟”实为未查询；需通过 Preload 预加载或封装方法手动按需查询，避免误将空切片当作懒加载结果。
Go 语言本身不支持运行时注解，所以 GORM 的延迟加载不是靠“标注字段自动懒查”，而是靠显式控制关联字段的加载时机——Preload 是预加载，Joins 是连接查询，而真正的延迟加载（Lazy Loading）在 GORM 中默认并不存在，必须手动实现或规避。
为什么 GORM 没有开箱即用的延迟加载？
GORM v2 不提供代理对象或运行时拦截字段访问的机制（如 Hibernate 的 LazyInitializationException 或 MyBatis 的 lazyLoadingEnabled），它把“是否查关联数据”的决定权完全交还给开发者。这意味着：
- 结构体中定义了
Employees []Employee关联字段，但不调用Preload("Employees")，GORM 就不会查它——这看起来像“延迟”，实则是“压根没查” - 一旦你访问
user.Employees，它只是个空切片，不会自动触发 SQL；想查，得自己写db.Where("dept_id = ?", user.ID).Find(&employees) - 所谓“延迟加载失效”，90% 是误以为 GORM 会像 Java ORM 那样自动代理，结果字段为空还硬取，导致 panic 或逻辑错误
如何手动模拟延迟加载行为？
在需要按需加载的场景（比如用户详情页只在点击“查看下属”时才查员工），推荐用封装方法替代字段直取：
type Department struct {
ID uint
Name string
}
func (d *Department) GetEmployees(db *gorm.DB) ([]Employee, error) {
var employees []Employee
return employees, db.Where("dept_id = ?", d.ID).Find(&employees).Error
}
这样既明确表达了意图，又避免了空切片误用。注意：
立即学习“go语言免费学习笔记（深入）”；
- 不要在结构体里加
Employees []Employee `gorm:"-"`然后靠方法补，否则序列化时容易漏字段 - 如果多个地方都要查，建议把
db作为参数传入，而非在结构体内存 db 实例（易引发 goroutine 安全问题） - 该模式下无法用 GORM 的链式条件（如
Order("created_at desc")），需在方法内显式拼接
Preload 不是延迟加载，但它能解决 N+1 问题
很多人混淆 Preload 和延迟加载。它是在主查询时**主动一次性加载关联数据**，典型用于列表页渲染：
var departments []Department
db.Preload("Employees", func(db *gorm.DB) *gorm.DB {
return db.Order("hire_date desc").Limit(5)
}).Find(&departments)
这段代码会生成 2 条 SQL：1 条查 department，1 条用 IN 查对应 employees。关键点：
-
Preload后，department.Employees是已填充的切片，不是代理对象 - 嵌套预加载写法是
Preload("Employees.Profile")，不是Preload("Employees").Preload("Profile")（后者无效） - 若关联字段是零值（如
DeptID为 0），Preload会跳过该条记录的关联查询，不会报错但可能不符合预期
真正要小心的是字段标签和零值陷阱
GORM 的结构体标签直接影响延迟相关行为，几个高频踩坑点：
-
gorm:"foreignKey:DeptID;constraint:OnUpdate:CASCADE,OnDelete:SET NULL;"：外键约束不影响加载逻辑，但删部门时员工 DeptID 变成 NULL，后续Preload就查不到——这不是延迟问题，是数据一致性问题 -
Employees []Employee `gorm:"serializer:json"`：加了序列化标签后，GORM 把整个切片当 JSON 存进一个字段，彻底失去关联查询能力 - 字段名大小写不匹配：
Employees对应表字段employees，但 GORM 默认按结构体字段名找外键，若写成employee就查不到——错误不报，只返回空切片
延迟加载在 Go 里从来不是框架特性，而是设计选择：你要么提前查好（Preload），要么自己动手查（封装方法），没有中间态。最容易被忽略的，其实是把“没查”当成“延迟查”，结果在生产环境突然发现关联数据永远为空。
