延迟加载是在访问节点时才查询其直接子节点，而非递归预加载；需配合惰性初始化、SQL精确过滤、分页限制、读写锁缓存及服务层隔离，严禁在GetChildren中调用递归函数。
延迟加载不是递归调用，而是按需查子节点
Go 中树形结构的“延迟加载”本质是：不一次性查全树，而是在访问某个节点时，才去数据库查它的直接子节点。这和 Preload 或递归预构建完全不同——它把查询时机从“初始化时”推迟到“首次访问 Children 字段时”。
常见错误是以为写个 func (n *Node) GetChildren() ([]*Node, error) 就算延迟加载，结果在 HTTP handler 里循环调用它，触发 N+1 查询；或者没加缓存，同一节点多次点开反复查库。
- 必须配合字段惰性初始化：比如定义
children []*Node私有字段 +loaded bool标记，GetChildren()先检查loaded再查库 - 数据库查询必须限定 parent_id = ?，不能查全表再 in-memory 过滤
- 如果前端支持分页（如展开某节点只拉前 20 个子项），SQL 要带
LIMIT和OFFSET，别把几千子节点全捞上来 - GORM 场景下慎用
db.Where("parent_id = ?", n.ID).Find(&children)：若未显式指定SELECT字段，可能拖慢响应；建议明确写db.Select("id,name,parent_id,...").Where(...)
递归函数不适合做延迟加载的主体逻辑
递归函数（如 getTreeRecursive）是一次性构建整棵树的工具，它和“延迟”天然冲突。你没法一边递归一边等用户点击再查下一层——那会卡死主线程，且无法中断或取消。
真实延迟加载场景中，递归只该出现在两个地方：一是前端 JS 层点击展开时发新请求；二是服务端收到“查 ID=123 的子节点”请求后，内部用递归查多层（但这是另一条独立请求路径，不是原树遍历的一部分）。
- 不要在
GetChildren()里调用getTreeRecursive：它会试图查出该节点所有后代，违背“只查直接子节点”的延迟原则 - 若业务真需要“展开时连带加载两层”，应在 API 层明确设计为
GET /nodes/{id}/children?depth=2，由 handler 控制递归深度，而非塞进模型方法 - 递归深度必须设硬上限（如
maxDepth := 3），避免恶意请求触发无限递归或栈溢出
用 sync.Once + map 实现安全的懒加载缓存
单次请求内多次访问同一节点的子节点，应该复用结果，而不是重复查库。但直接在 struct 里放 children []*Node 字段并赋值，会破坏数据一致性（比如其他 goroutine 同时更新了 DB）。正确做法是用 sync.Once 配合局部缓存。
示例结构体：
type Node struct {
ID int
ParentID int
Name string
mu sync.RWMutex
children []*Node
loaded bool
}
func (n *Node) GetChildren(db *gorm.DB) ([]*Node, error) {
n.mu.RLock()
if n.loaded {
defer n.mu.RUnlock()
return n.children, nil
}
n.mu.RUnlock()
n.mu.Lock()
defer n.mu.Unlock()
if n.loaded {
return n.children, nil
}
if err := db.Where("parent_id = ?", n.ID).Find(&n.children).Error; err != nil {
return nil, err
}
n.loaded = true
return n.children, nil
}
- 注意
sync.RWMutex的读写锁分离：多数情况是并发读，只在首次加载时写 - 不要用
sync.Once替代锁：Once 只保证“执行一次”，不保证并发安全地返回结果；多个 goroutine 同时调GetChildren仍可能竞争写n.children - 缓存只在单次请求生命周期内有效；不要把
Node实例长期存在全局 map 里，否则 DB 更新后缓存永远不刷新
GORM 关联字段不能直接用于延迟加载
GORM 的 Children 字段如果声明为 Children []Child `gorm:"foreignKey:ParentID"`，它只是个 ORM 映射标记，不代表自动延迟加载。调用 db.First(&node) 时，node.Children 默认是空 slice，不会触发任何查询；只有显式调用 db.Preload("Children").First(&node) 才会查，而且是立即、同步、无条件查全量。
- 别给
Children字段加gorm:"-"然后自己实现 getter：这会让 GORM 序列化 JSON 时忽略该字段，前端拿不到数据 - 更稳妥的是把延迟加载逻辑完全剥离出模型，例如定义独立 service 方法：
nodeService.GetChildren(ctx, nodeID)，由上层决定是否缓存、是否限流、是否加 trace - 若必须嵌入模型，建议用指针字段
Children *[]*Node，初始为 nil，getter 中分配并填充，这样 JSON 序列化时可控制是否输出空数组
延迟加载真正难的不是代码怎么写，而是边界怎么划：哪些节点允许延迟、哪些必须预热、超时怎么设、错误是静默丢弃还是向上抛、缓存失效策略怎么定——这些都没法靠一个递归函数解决。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
