Django 2.0+ 强制 ForeignKey 和 OneToOneField 必须显式设置 on_delete，否则报 TypeError；常用选项有 CASCADE、PROTECT、SET_NULL、SET_DEFAULT；ManyToManyField 无 on_delete，中间表需手动清理；级联删除需警惕 N+1、信号递归及性能问题。
ForeignKey 一对多关系里，on_delete 参数不设清楚会直接报错
Django 2.0+ 强制要求 ForeignKey 必须显式声明 on_delete，漏写会抛 TypeError: __init__() missing 1 required positional argument: 'on_delete'。这不是警告，是运行时硬性拦截。
-
on_delete=models.CASCADE：关联对象删了，本条也删（最常用，但容易误删） -
on_delete=models.PROTECT：想删父对象时直接抛ProtectedError，适合关键主表（如用户删了，订单不能自动消失） -
on_delete=models.SET_NULL：需配合null=True，父对象删后外键字段变NULL -
on_delete=models.SET_DEFAULT：要求字段有default=...，且该默认值在父表中真实存在（否则保存失败）
OneToOneField 一对一删除默认不级联，得手动加 on_delete
很多人以为 OneToOneField 天然级联，其实它和 ForeignKey 一样，默认不设 on_delete 就报错，且行为完全一致——没设就是语法错误，不是“默认不删”。
- 典型场景：用户扩展信息表
UserProfile关联User，删用户时要不要删资料？取决于业务 - 如果要级联删，必须写
on_delete=models.CASCADE，别指望它自己猜 - 如果资料表可独立存在（比如用户注销后保留审计数据），用
on_delete=models.SET_NULL+null=True
ManyToManyField 多对多没有 on_delete，但中间表删除逻辑藏在反向操作里
ManyToManyField 本身不接受 on_delete 参数，因为它的关联存在独立中间表，删模型实例时不会动中间表记录——但反向操作（如 user.groups.clear()）会清关联，这点容易被忽略。
- 删 A 对象时，B 表数据不动，A-B 中间表对应行也不动（除非你显式调用
remove()或clear()） - 真正触发中间表清理的是反向管理器方法：
obj.m2m_field.clear()、obj.m2m_field.remove(b_obj) - 如果要用级联语义，得在视图或信号里手动处理，比如
post_delete里遍历并删中间关系
级联删除可能触发意外的 N+1 或事务膨胀，尤其带信号或自定义 delete() 时
看似一个 .delete() 调用，背后可能触发几十次数据库查询或信号回调，特别是模型有 pre_delete/post_delete 信号、或重写了 delete() 方法时。
立即学习“Python免费学习笔记（深入）”；
- Django 的
CASCADE是 ORM 层模拟的，不是数据库原生 FK 级联（除非你手动在 DB 层加ON DELETE CASCADE） - 如果子表有上万条记录，
CASCADE可能卡住请求，建议大表改用软删除或异步任务清理 - 信号里再触发另一个
.delete()容易造成递归或死锁，务必检查是否已进入删除流程（可用instance._state.adding is False辅助判断）
on_delete 不是填完就完事，它绑定的是整个删除链路的语义起点——后面所有信号、索引、事务边界都从这里发散。稍不注意，删一条用户就顺手把三年日志全清了。 
