多态关联删除不能直接用destroy()或delete()链式调用，必须显式查出子记录ID后逐条或批量删，否则会漏删、报错或触发错误SQL；因delete()是模型实例方法不支持查询构造器链式调用，且morphMany外键和类型字段不参与主键索引，destroy()无法定位记录。
多态关联删除不能直接用 destroy() 或 delete() 链式调用，必须显式查出子记录 ID 后逐条或批量删，否则会漏删、报错或触发错误 SQL。
为什么 where()->delete() 在多态关联里不生效
ThinkPHP 的 delete() 是模型实例方法，不支持在查询构造器上链式调用；而多态关联（如 morphMany）的外键和类型字段（type/type_id）又不参与主键索引，destroy() 无法根据非主键条件定位记录。常见现象是：代码看似执行成功，但数据库里子表（如评论表）一条没删。
错误写法示例：User::where('id', 123)->delete()（报错：Call to undefined method delete）Comment::where('type', 'app\model\User')->where('type_id', 123)->delete()（语法合法但不是模型层删除，跳过事件、软删除逻辑）
正确思路是：先确认你要删的是哪个“拥有方”（比如 User），再反向查出它在多态子表里的全部 id，最后用 destroy() 批量删。
立即学习“PHP免费学习笔记（深入）”；
morphMany 关联删除必须手动处理类型字段映射
如果用了自定义多态字段名（如 subject_type/subject_id）或短类名映射（如存 user 而非 app\model\User），destroy() 和 with() 都会失效——因为底层 SQL 的 WHERE 条件仍按默认字段和完整类名拼接。
实操建议：
- 删之前先用
Db::name('comment')->where('subject_type', 'user')->where('subject_id', $userId)->column('id')拿 ID 列表 - 确保
subject_type的值与你数据库里存的实际字符串完全一致（大小写、命名空间、斜杠方向） - 若用短名映射，删前需手动转成完整类名：
$realType = $typeMap[$shortType] ?? $shortType，再传入查询 - 别依赖
Comment::where(...)->delete()，它绕过模型，不会触发deleting事件，附件、缓存等联动逻辑得自己补
关联删除时软删除状态必须显式判断
多态子表若启用软删除（如 delete_time 字段），destroy() 默认只删「未软删除」的记录。如果你要连同已软删除的也清掉，得加条件：
Comment::where('type', 'app\model\User')->where('type_id', $userId)->useSoftDelete(false)->delete() —— 注意这不是模型方法，而是 Db 查询；若坚持走模型，得先 withoutGlobalScope(SoftDelete::class)，再查 ID 再 destroy()。
容易踩的坑：
-
destroy()不识别软删除配置，它只认主键存在与否 -
withTrashed()是 Laravel 写法，ThinkPHP 没这个方法，别抄错 - 用
Db::name('comment')->where(...)->delete()硬删时，delete_time字段不会被自动设值，也不会清空，得自己->update(['delete_time' => 0])或直接->delete()
大批量多态删除必须分页 + 显式事务
一次删几千条多态子记录（比如清理历史用户所有评论），直接 destroy($ids) 容易超内存或锁表。ThinkPHP 不会自动分批，得你自己控。
推荐做法：
- 用
limit(500)分批查 ID：Comment::where('type', ...)->where('type_id', ...)->limit(500)->column('id') - 每次拿到 ID 数组后，用
destroy()批量删，并检查返回值是否等于数组长度 - 外层包
Db::transaction()，确保某一批失败时能回滚，避免删一半卡住 - 别用
all()->each(function ($c) { $c->delete(); })，实例化开销大，1000 条就可能 OOM
最常被忽略的一点：多态删除没有「级联」机制。哪怕你在 User 模型里写了 protected $deleteTime = 'delete_time'，它也不会自动删 Comment；所有子表逻辑都得在业务层显式写清楚，一个字段配错、一个映射漏掉，数据就残留在那里了。
