detach() 不解析关联方法中的 where() 条件，只根据主键清空全部关联记录；需用 wherePivot() 过滤中间表字段，或手动提取 ID 列表再 detach。

直接调用带 where() 条件的关联方法后执行 detach()，不会按条件解绑——它会清空整个中间表里该模型的所有关联记录。这是 Laravel 多对多关系中最容易踩坑的操作之一。

为什么 workers()->detach() 会删光所有关联？

detach() 不解析、不继承你在关系方法中写的 where() 或作用域逻辑。它只做一件事：根据当前模型的主键（如 organization_id），生成类似 DELETE FROM organization_people WHERE organization_id = ? 的 SQL。中间表里的 type、status 等字段完全被忽略。

• 错误写法：$this->workers()->detach()，其中 workers() 是 $this->people()->where('type', 3)
• 实际效果：删掉该组织在 organization_people 表中的全部记录，不管 type 值是多少
• 根本原因：detach() 底层不走 Eloquent 查询构建器的 WHERE 链，而是直接构造 DELETE 语句

wherePivot() 是唯一能让 detach() 自动生效的过滤方式

只有当你要过滤的字段（比如 type）真实存在于中间表（如 organization_people）时，wherePivot() 才有效。它会被 detach() 内部识别，并拼进 DELETE 语句的 WHERE 子句中。

Laravel Cloud

Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。

下载

• 正确写法：$this->people()->wherePivot('type', 3)->detach()
• 生成的 SQL 类似：DELETE FROM organization_people WHERE organization_id = ? AND type = 3
• 注意：wherePivot() 不能用于过滤关联模型本身的字段（如 people.status），那必须走 ID 提取方案
• 前提：中间表必须真有这个字段，且已通过 withPivot(['type']) 声明过

手动提取 ID 列表是最通用、最可控的解绑方式

当你需要基于关联模型字段（如 people.deleted_at IS NULL）、软删除状态、或中间表字段不在标准命名规则下时，先查 ID 再传给 detach() 是唯一可靠路径。

• 示例：$ids = $this->people()->where('people.status', 'active')->pluck('people.id')->toArray(); $this->people()->detach($ids);
• 关键点：pluck('people.id') 中的 people. 前缀必须与关联查询实际使用的表别名一致（默认是模型小写复数）
• 性能提示：如果数据量大，避免在事务外多次查询；可考虑用子查询或原生 SQL 优化，但语义清晰优先
• 安全边界：detach() 只删中间表记录，不触发关联模型的 deleting 事件，这点和 delete() 本质不同

真正难的不是写对代码，而是判断 type 这类字段到底属于“人”还是“关系”。前者只能靠 ID 提取，后者才能用 wherePivot()；一旦混淆，detach() 就会静默越界。