GORM的Save()和Updates()默认不处理多对多关联变更，需用Association().Delete()显式删除；Clear()+Append()易致死锁，Replace()适合全量替换而非单条删除。
Save() 和 Updates() 默认不处理多对多关联变更
很多人以为给结构体的 Languages 切片删掉一个元素再调用 Save()，GORM 就会自动删掉中间表那条记录。事实是：它完全忽略切片内容变化，只更新主模型字段。即使你设置了 gorm:save_associations:true 标签，这个标签也只影响 Create() 和全量 Save()（即新建或整条覆盖），对“部分删除”无任何作用。
跳过自动保存的正确姿势：显式调用 Association().Delete()
想精准移除某条多对多关系（比如用户和语言的关联），必须绕过 GORM 的自动关联逻辑，直接操作关联表：
-
db.Model(&user).Association("Languages").Delete(&language)—— 传入已加载、有有效ID的实例指针 -
db.Model(&user).Association("Languages").Delete(&Language{ID: 5})—— 传入仅含ID的匿名实例，无需预先查库 -
db.Model(&user).Association("Languages").Delete(1, 2)—— 直接传主键值，最轻量
该方法生成的是单条 DELETE FROM user_languages WHERE user_id = ? AND language_id = ?，不查数据、不触发钩子、不锁全表，性能和语义都干净。
别踩 Clear() + Append() 这个坑
有人试图手动清空再重填来“模拟删除”，比如先 Clear() 再 Append() 剩下的语言。这会导致两轮 SQL：DELETE FROM user_languages WHERE user_id = ? + 多条 INSERT。在并发写入或大数据量下，极易引发锁等待甚至死锁。而且 Clear() + Append() 不是原子操作，中间状态可能被其他请求读到。
Replace() 是全量替换，不是跳过而是另起一套机制
Association().Replace() 确实会跳过自动保存逻辑，但它走的是“先清空 + 再插入”的事务内原子流程，适合重置全部关联。如果你只是删一条，用它就属于大炮打蚊子——多一次全表 DELETE，还多几条 INSERT，纯属浪费。
真正要跳过自动保存，核心就一条：别依赖结构体切片变化，改用 Association().Delete() 显式控制。最容易被忽略的是传参类型——传零值结构体或没设 ID 的指针，Delete() 会静默失败，连错误都不报。
