Laravel 没有自动同步关联更新，sync()仅适用于多对多关系且全量覆盖中间表；一对多/一对一需手动处理增删改，务必用事务包裹并避免误删。
直接说结论：Laravel 没有“自动同步关联更新”这回事，sync()、attach()、detach() 只作用于多对多关系，且不触发模型事件或验证；一对多/一对一更新必须手动处理，否则数据会错位甚至丢失。
什么时候该用 sync()？只限多对多中间表
sync() 的唯一合法场景是更新 belongsToMany 关系的中间表（pivot）记录。它会先清空当前关联，再插入新 ID 列表——不是“增量更新”，而是“全量覆盖”。
- 传入
[1, 3, 5]，中间表里只保留这三条记录，其他全部删掉 - 传入空数组
[]，相当于“解除所有关联”，中间表对应行全删 - 如果想保留原有记录并追加，得用
attach()；想只删不加，用detach() -
sync()不调用creating/updating等模型事件，也不走save()的验证逻辑
一对多更新别碰 sync()，否则子记录被误删
常见错误：把 hasMany 当成多对多，对子模型集合调用 sync() —— 这根本不会生效，因为 sync() 在一对多关系上不存在。更危险的是，有人手动写 foreach + delete() 再重建，结果漏掉软删除判断或事务包裹，导致数据不一致。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 正确做法是：先查出已有子记录 ID，再对比新数据 ID 列表，分别执行
create()、update()、delete() - 涉及状态变更（如启用/禁用）时，优先用
upsert()（Laravel 9+）避免 N+1 和竞态 - 务必在事务中操作：
DB::transaction()包裹整个流程，否则部分失败会导致主从数据断裂
syncWithoutDetaching() 不是万能补丁，它只适用于特定 pivot 字段更新
syncWithoutDetaching() 表面看像“安全版 sync”，但它只在多对多且带额外 pivot 字段（比如 role_id、expires_at）时才有意义。它不会删记录，而是对已存在关联做 update，对新 ID 做 insert。
- 参数必须是
[$id => $pivotData]形式，例如[2 => ['role' => 'editor']] - 如果只传
[2, 3]（纯 ID 数组），它和sync()行为一样：删旧、插新，但不更新 pivot 字段 - 它依然不触发模型事件，也不校验子模型的
fillable或casts
真正要同步业务逻辑，得靠观察者或显式调用
比如用户更新角色后需刷新权限缓存，或者订单状态变更为“已发货”时要创建物流单——这些都不是数据库关联能自动完成的，必须由你控制时机。
- 在控制器里显式调用：
$user->roles()->sync($request->role_ids); cache()->forget("permissions:{$user->id}"); - 用模型观察者监听
updated事件，但注意：观察者收不到sync()触发的中间表变更，只能监听模型本身的save() - 复杂场景建议抽成 Service 类，把“关联变更”和“业务副作用”解耦，比如
UserRoleSyncService::handle($user, $newRoleIds)
最常被忽略的一点：sync() 和 upsert() 都绕过 Eloquent 的属性转换（casts）、访问器（getFooAttribute）和验证规则。如果你依赖这些逻辑做数据清洗，必须在调用前自己处理干净。
