association().delete() 只删除中间表关系记录，不影响被关联的主表实体；它不触发级联删除，也不操作主表，仅用于解绑关系。
Association().Delete() 不会删主表记录，只动中间表
很多人误以为 Association().Delete() 是在删关联的子实体（比如 Language），其实它只删除中间表（如 user_languages）里的那条关系记录。被关联的 Language 行本身完全不受影响——这是设计上的明确分离：关系管理 ≠ 实体生命周期管理。
常见错误现象是：调用后发现 Language 记录消失了，那大概率是你在别处写了 db.Delete(&lang) 或启用了级联删除（foreignKey:... onDelete:CASCADE），和 Association() 无关。
- 正确使用场景：用户取消选修某门语言、移除某个标签、解绑某个权限
- 参数差异：
db.Model(&user).Association("Languages").Delete(&lang)删除单个；传入切片可批量删多个 - 性能影响：只发一条
DELETE FROM user_languages WHERE user_id = ? AND language_id IN (?)，不查主表，极快
Save() 修改关联切片完全无效，GORM 不监听结构体字段变更
Save() 和 Updates() 对结构体里的关联切片（如 user.Languages）彻底“视而不见”。你把切片清空、追加、截断，再 db.Save(&user)，GORM 只会更新 user 主表字段（name、updated_at 等），中间表纹丝不动。
这是 GORM 的明确行为约定，不是 bug。它的底层逻辑是：关联状态变更必须通过 Association() 显式表达，避免隐式副作用。
- 典型翻车写法：
user.Languages = []Language{}+db.Save(&user)→ 中间表没变化 - 替代方案只有两个：
Association().Clear()（全删）或Association().Delete(...)（删指定） - 如果真想“保存整个树”，得用
FullSaveAssociations:true会触发 Upsert，但那是创建/更新整条链，不是删关系
Association().Replace() 的坑：它先 Clear 再 Append，不是“合并”
Association().Replace() 容易被误解为“增量同步”——比如原有关联 A、B，新传入 B、C，以为结果是 A、B、C 或只是 B、C。实际它执行的是原子操作：先删所有旧关系，再插入新列表中的全部项。
这意味着即使 B 已存在，也会被先删再插，中间表会多一次无谓的 DELETE+INSERT。如果你只想增补 C，应该用 Association().Append(&c)；如果只想删 A，就用 Association().Delete(&a)。
- 适用场景：用户重新提交完整标签列表、角色权限全量覆盖
- 注意外键约束：若新列表里有不存在的
LanguageID，Replace 会报外键错误，而Delete()不会 - 没有“upsert 关系”内置方法，需自己先查再判断 Append/Remove
Association 方法必须基于已加载或已知主键的模型实例
db.Model(&user).Association("Languages") 要求 user 至少有有效的主键值（如 ID != 0）。如果 user 是刚 new 出来的空结构体，或者从数据库查出来时没带主键（比如用了 Select("name")），调用 Association() 会静默失败或 panic。
更隐蔽的问题是：如果 user 是从 Preload 加载的，但中间表字段被 Select 过滤掉，Association() 仍能工作（因为它只依赖主键），但你无法通过 user.Languages 切片看到当前状态——这容易导致“删了又删”或“以为删了其实没删”的错觉。
- 安全做法：确保
user.ID > 0，且优先用First()或带主键的查询加载实例 - 调试技巧：开启
db.Debug()，看生成的 SQL 是否含正确的WHERE user_id = ? - 不要依赖
user.Languages切片内容做逻辑判断，它只是缓存，不是权威状态
