事务中更新树状结构必须显式预加载全路径并手动更新每个节点，GORM不自动递归处理父子关系；需用Preload加载整棵树、map更新避免零值丢失、禁止在钩子中跨记录操作，外键级联不解决非外键字段继承。
事务中更新树状结构必须显式加载全路径
直接对根节点调用 Save 或 Updates 不会自动递归更新子节点——GORM 不识别“树形”语义，它只按结构体字段映射关系操作。如果你的模型是 Category 带 ParentID 和 Children 切片，那 Children 字段默认不会被加载，更不会被写入。
常见错误现象：db.Transaction(...) 里修改了根节点的 Name 并 Save，但子节点字段（如 Slug）没变；或者事务提交后子节点仍处于旧状态，甚至因外键约束失败而回滚。
- 必须用
Preload显式拉取整棵树，且层级要够深（Preload("Children.Children")等） - 若树深度不确定，建议改用闭包表（Closure Table）或路径枚举（
Path字段），避免无限递归预加载 -
Preload后需手动遍历修改每个节点，不能只改根节点再Save整个切片——GORM 不会自动识别父子关系变更
级联更新不能依赖 BeforeUpdate 钩子
BeforeUpdate 在单条记录上下文中执行，拿不到兄弟节点或子树上下文。你无法在某个 Category 的钩子里安全地触发其所有后代的更新，因为此时 Children 字段为空（未预加载），且钩子不运行在事务主流程内，容易造成部分更新成功、部分失败。
典型陷阱：BeforeUpdate 里调用 db.Model(&c).Where("parent_id = ?", c.ID).Updates(...)，这会跳出当前事务，新建连接执行，破坏原子性。
- 所有树节点的更新逻辑必须写在同一个
db.Transaction函数体内 - 禁止在钩子里做跨记录写操作；钩子只适合做单行字段计算（如生成
Slug）、校验或日志 - 如果必须复用逻辑，把更新函数定义为接受
*gorm.DB和节点列表的纯函数，由事务统一传入
用 map 更新比 struct 更可靠
树节点常含零值字段（如 SortOrder: 0、IsPublished: false），用 struct 调用 Updates 会跳过这些字段，导致意外丢失更新。
例如：cat.Updates(Category{SortOrder: 0, IsPublished: false}) 实际什么都不会更新，因为 GORM 默认忽略零值。
- 统一用
map[string]interface{}：cat.Updates(map[string]interface{}{"sort_order": 0, "is_published": false}) - 若字段名与数据库列名不一致（如 Go 字段
IsPublished→ DB 列is_published），确保 map key 是列名（小写下划线），或用Select指定字段：cat.Select("is_published").Updates(Category{IsPublished: false}) - 批量更新多个节点时，避免循环中反复调用
Updates，改用db.Table("categories").Where("id IN ?", ids).Updates(...)减少 round-trip
外键级联只解决删除，不解决更新
很多人误以为加了 ON UPDATE CASCADE 就能自动同步父节点字段到子节点（比如改了父节点 status，子节点也跟着变）。但这是错的：数据库外键级联只作用于外键列本身（如 parent_id），不传播非外键字段。
也就是说，即使你把 parent_id 改成另一个 ID，数据库可以自动更新子节点的 parent_id，但它不会帮你把子节点的 status 设成新父节点的 status。
- 树形数据的字段继承（如
IsPublished自上而下传递）必须由应用层控制，在事务中显式赋值 - 不要试图用触发器模拟这种行为——它绕过 GORM 生命周期，难以调试，且与软删除、钩子等机制冲突
- 真正需要字段继承的场景，建议冗余存储（如每个节点存
root_id和ancestors_path），查询时用 WHERE 条件过滤，而非靠级联更新保证一致性
Save 或 Updates，否则它们的变更永远不会落到数据库**。没人会记得给每个子节点补一句 db.Save(&child)，但漏掉就是数据不一致。 
