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() 就会静默越界。
