软删除在symfony中需标记+过滤并确保级联一致性：禁用doctrine物理级联，业务层手动处理子实体deletedat；关联查询须显式过滤；恢复操作需双向同步；真删须经白名单、校验与日志记录。
软删除在 Symfony 中不是“删掉就完事”，而是把删除动作转为标记 + 过滤，真正难点在于级联关系下的数据一致性。尤其当一个被软删除的父实体（比如 Category）关联着多个子实体（如 Product、Post），这些子实体是否该跟着“逻辑删除”？怎么保证查不到、改不了、也导不出？这需要分层设计，不能只靠注解打钩。
软删除必须显式控制级联行为
Doctrine 默认的 cascade={"remove"} 是物理删除，和软删除冲突——它会直接执行 SQL DELETE，绕过你的 deletedAt 字段。所以第一步：禁用所有自动级联删除。
- 在父实体的关联映射中，移除
cascade={"remove"}，哪怕你写了softdeleteable注解也不起作用 - 把级联逻辑收回到业务层：比如用户点击“删除分类”，你要手动遍历并设置每个关联
Product的deletedAt - 如果子实体也有自己的软删除字段，那就逐层设；如果没有，可考虑加字段或用“软删除感知型关联查询”（见下条）
关联查询要自动过滤已软删除项
即使父实体没被软删除，只要它的某个子项已被标记删除，标准 findAll() 或 findBy() 仍会把它拉出来——因为 Doctrine 的 DQL 过滤器只作用于主实体，不穿透关联。
- 在自定义 Repository 方法中，显式加
WHERE child.deletedAt IS NULL条件 - 用
leftJoin()+with()构建查询，避免 N+1 同时确保子项也被过滤 - 若需统一处理，可在子实体上也启用
@Gedmo\SoftDeleteable，让过滤器自动生效（前提是子实体也配了扩展）
恢复操作必须双向同步
用户点“还原分类”，不只是把 Category::deletedAt 设为 null，还要决定子项是否一并还原。
- 默认不还原子项：保留历史隔离性，适合审计场景
- 主动还原子项：需在业务逻辑里遍历子集合，逐一清空其
deletedAt，再$em->flush() - 禁止部分还原：加数据库约束或应用层校验，比如子项有独立操作记录时，不允许父项还原触发子项状态变更
真删（硬删除）要加白名单与确认机制
软删除本意是防误删，但总有清理归档数据的需求。这时必须严格限制：
- 只允许通过 CLI 命令或后台管理接口执行，且需输入二次确认码或管理员权限验证
- 执行前检查关联：若子实体存在且未软删除，拒绝真删；或强制先软删全部关联项
- 记录操作日志，包含时间、操作人、影响行数，不可覆盖不可删除
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
