deleteall 直接执行 delete sql，不加载实体，因此完全绕过 beforedelete/afterdelete 等生命周期事件、ruleschecker 校验及软删除逻辑；需用 find() + deletemany() 保留事件触发，或 updateall() 配合手动处理。
deleteAll 直接绕过实体生命周期，事件不会触发
deleteAll 是 CakePHP 的 Table 层方法，底层走的是 QueryBuilder + DELETE SQL，不加载任何实体（Entity），因此 beforeDelete、afterDelete 等实体事件完全不会执行。如果你依赖这些事件做日志、缓存清理或关联删除，用 deleteAll 就等于跳过了整个业务逻辑链。
常见错误现象：deleteAll(['status' => 'draft']) 成功删了 200 条，但审计表没写入、Redis 缓存没失效、软删除字段也没更新——因为事件压根没跑。
用 find() + deleteMany() 保留事件触发能力
想批量删又想走事件，核心思路是：先查出实体，再批量交由 Table::delete() 处理。CakePHP 4.4+ 原生支持 deleteMany()，它会对每个实体依次调用 delete()，从而触发完整生命周期。
- 必须用
find('all')或带select()的查询，不能用find('list')等只取部分字段的 finder，否则构造不出完整实体 - 注意内存：一次性 load 几千条实体可能 OOM，建议分页处理（比如每 100 条一批）
- 事务需手动包裹：
$table->getConnection()->begin();+ 异常时 rollback，否则中途失败会导致部分删除、部分未删
示例：
$query = $articles->find()
->where(['status' => 'draft'])
->limit(100);
$entities = $query->all();
if ($entities->count() > 0) {
$articles->deleteMany($entities->toList());
}
软删除场景下 deleteAll 完全不可用
如果项目用了 TimestampBehavior 或自定义软删除（比如加 deleted 字段），deleteAll 会直接物理删除，彻底无视软删逻辑。这时候连“恢复误删”都做不到。
替代方案只有两条路：
- 改用
patchEntities()+saveMany()手动设deleted => true和deleted_date，再触发事件（适合已有软删约定） - 用
updateAll()更新状态字段（快但不触发事件，需额外补日志或清理逻辑）
注意：deleteAll() 不管你有没有配置 SoftDeleteBehavior，它永远发 DELETE 语句。
性能敏感场景：事件可关，但得关得明白
真要追求极致删除速度（比如后台清理百万级日志），可以临时禁用事件，但别靠删代码或注释——用 CakePHP 提供的开关更安全：
- 临时关闭：
$table->getEventManager()->off('Model.beforeDelete');（记得删完 restore） - 或者在
deleteAll()前设置$table->setEventEnabled(false)（4.4+ 支持） - 切勿在生产环境长期关闭事件，尤其涉及权限校验或数据一致性检查的场景
最易被忽略的一点：即使关了事件，deleteAll 仍不会调用 RulesChecker，规则校验形同虚设。如果业务要求“只有管理员能删某类数据”，这个校验必须前置到查询条件里，而不是指望事件或规则层拦住。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
