直接重写 delete_view 不够用，因为 django admin 删除流程分 get 确认页和 post 执行两步，确认页由 delete_confirmation.html 渲染，数据来自 get_deleted_objects 和 has_delete_permission，而非 delete_view 控制。
为什么直接重写 delete_view 不够用
Django Admin 的删除流程分两步：先 GET 请求展示确认页，再 POST 提交执行删除。很多人以为重写 delete_view 就能接管全部逻辑，结果发现 GET 阶段的确认页仍显示默认提示、不校验业务规则、也无法动态禁用删除按钮——因为确认页由 delete_confirmation.html 模板渲染，其数据来自 get_deleted_objects 和 has_delete_permission，不是 delete_view 控制的。
如何在确认页前插入自定义校验和拦截
关键是在用户点击“删除”后、渲染确认页前介入。Django Admin 会调用 get_deleted_objects 获取待删对象依赖关系，同时检查权限。你得在这里注入业务判断：
- 重载
get_deleted_objects，在调用父类方法后检查返回的deleted_objects或原始 queryset，抛出PermissionDenied（会转为 403 页面）或改写perms_needed列表触发权限拒绝提示 - 若需更友好的提示，可结合
has_delete_permission返回 False，并在changelist_view中通过self.message_user提前警告（但注意：这无法阻止用户手动构造 URL 访问删除页） - 真正可靠的拦截点是重写
delete_view，并在 super() 调用前加判断：检查request.method == 'POST'时做最终校验；request.method == 'GET'时可提前 redirect 或 raiseHttpResponseForbidden
怎么让确认页显示自定义提示而非默认文本
默认确认页只显示“要删除 X 条记录？”，不展示业务原因。要加说明，必须修改模板上下文：
- 重写
delete_view，在调用父类前设置extra_context = {'reason': '该订单已发货，不可删除'}，然后传给super().delete_view(..., extra_context=extra_context) - 在自定义模板
admin/myapp/mymodel/delete_confirmation.html中使用{{ reason }}输出 - 注意：Django 3.2+ 默认使用
django.contrib.admin.views.main.get_deleted_objects，它不接受额外参数，所以不能靠它传参；一切上下文必须走extra_context或 request.session
绕过 Model.delete() 直接硬删时的陷阱
有些场景要求跳过 model 层的 save() 或信号，用 QuerySet.delete() 批量删。但 Admin 的 delete_view 默认调用的是 obj.delete() 单条删除——性能差且触发信号。想优化，得自己实现：
- 在
delete_view的 POST 分支中，拿到self.get_queryset(request)，筛选出选中的对象 ID，再用MyModel.objects.filter(id__in=ids).delete() - 但必须同步清理 admin 日志（
LogEntry.objects.filter(object_id__in=ids, content_type=ct)），否则后台“操作历史”里会残留已删对象的记录 - 更要紧的是：Django 不会自动触发
pre_delete/post_delete信号，如果业务逻辑依赖这些信号（比如清理关联缓存），就得手动send
最易被忽略的是：Admin 删除确认页本身不校验 has_delete_permission 的返回值是否随对象状态动态变化——它只检查一次，且缓存结果。如果你的权限逻辑依赖数据库字段（如 status == 'draft' 才可删），务必在 has_delete_permission 中传入 obj 参数并实时查库，而不是只看 request.user 角色。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
