直接重写exception_handler不生效，是因为Django 5+中500类异常被中间件提前拦截，未进入DRF处理流程；需同时配置全局异常中间件和自定义exception_handler才能真正兜底。
为什么直接重写 exception_handler 不生效？
因为 Django 5 + DRF 3.14+ 默认启用了 DEFAULT_EXCEPTION_HANDLER 的新行为：它只处理视图层抛出的异常（如 ValidationError、PermissionDenied），而 500 类错误（比如未捕获的 ValueError、数据库连接中断）根本不会进到这个函数里——它们被 Django 的中间件链提前拦截了。
所以光改 exception_handler，只能覆盖“DRF 规范异常”，漏掉大量真实线上崩溃场景。
- 常见现象：
ZeroDivisionError或自定义逻辑里的raise Exception("xxx")直接返回 HTML 500 页面，而不是 JSON 错误响应 - 根本原因：Django 的
BaseHandler.get_response()在中间件之后才调用exception_handler，但非 DRF 异常在进入视图前或中间件中就已触发response = response_exception(...) - 正确做法：必须同时接管 DRF 的
exception_handler和 Django 的全局异常中间件
怎样写一个真正兜底的全局异常中间件？
在 middlware.py 里加一个类，放在所有中间件最末尾（确保它能捕获其他中间件没处理的异常）：
class GlobalExceptionMiddleware:
def __init__(self, get_response):
self.get_response = get_response
<pre class="brush:php;toolbar:false;">def __call__(self, request):
return self.get_response(request)
def process_exception(self, request, exception):
# 只对 API 请求返回 JSON，避免干扰 admin / static 等页面
if not request.path.startswith('/api/'):
return
import json
from django.http import JsonResponse
from django.conf import settings
status_code = 500
error_msg = "Internal Server Error"
if hasattr(exception, 'status_code'):
status_code = getattr(exception, 'status_code', 500)
if hasattr(exception, 'default_detail'):
error_msg = str(getattr(exception, 'default_detail', error_msg))
# 生产环境不暴露 traceback
if settings.DEBUG:
error_msg += f" — {type(exception).__name__}: {str(exception)}"
return JsonResponse({
"code": status_code,
"message": error_msg,
"data": None
}, status=status_code)
然后在 settings.py 的 MIDDLEWARE 列表末尾加上：
'myapp.middleware.GlobalExceptionMiddleware',
- 注意路径判断逻辑要和你的 API 前缀一致（比如用
/v1/就改成request.path.startswith('/v1/')） - 不要在中间件里做耗时操作（如发邮件、写 DB），避免阻塞请求生命周期
-
process_exception是 Django 提供的标准钩子，比 try/except 包裹整个get_response更轻量、更可靠
如何安全地重写 DRF 的 exception_handler？
在 exceptions.py 中定义新 handler，并在 settings.py 显式覆盖：
from rest_framework.views import exception_handler
from rest_framework.response import Response
<p>def custom_exception_handler(exc, context):</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill11526" title="Python Hardener"><img
src="https://img.php.cn/upload/skill/001/246/273/6adaf20dbae7c507.jpg" alt="Python Hardener" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill11526" title="Python Hardener" class="overflowclass">Python Hardener</a>
<p class="overflowclass">通过完整的安全审查、代码整洁重构、健壮的错误处理、正确的日志记录以及完整的文档字符串覆盖，强化 Python 脚本。</p>
</div>
<a rel="nofollow" href="/xiazai/skill11526" title="Python Hardener" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><h1>先让 DRF 原逻辑处理（生成标准 Response）</h1><pre class="brush:php;toolbar:false;">response = exception_handler(exc, context)
# 如果 DRF 已经处理好了（比如 400/403/404），就微调结构
if response is not None:
response.data = {
"code": response.status_code,
"message": response.data.get('detail') or str(exc),
"data": response.data
}
return response
# 如果 DRF 没处理（比如 500），这里兜底（但注意：实际应由上面中间件处理，此处仅防漏）
return Response({
"code": 500,
"message": "Server Error",
"data": None
}, status=500)
再在 settings.py 中设置：
REST_FRAMEWORK = {
'EXCEPTION_HANDLER': 'myapp.exceptions.custom_exception_handler',
}
- 务必保留原
exception_handler调用，否则会丢失 DRF 对ParseError、NotAuthenticated等的自动转换逻辑 - 不要在
custom_exception_handler里 raise 新异常，会导致二次进入中间件，可能死循环 - 如果用了
APIView.as_view()以外的方式（如函数视图@api_view），这个 handler 依然有效；但纯 DjangoView子类不走这里
调试时怎么快速定位是哪个环节截断了异常？
加两行日志就能看清流向：
在中间件的 process_exception 开头加：
import logging
logger = logging.getLogger(__name__)
logger.error(f"[GlobalMiddleware] Caught: {type(exc).__name__} @ {request.path}")
在 custom_exception_handler 开头加：
logger.debug(f"[DRF Handler] Handling: {type(exc).__name__}")
- 如果只看到 middleware 日志，没看到 handler 日志 → 说明异常根本没进 DRF 流程（比如发生在认证中间件里、或 URL 解析失败）
- 如果只看到 handler 日志，没看到 middleware 日志 → 说明是标准 DRF 异常（如序列化失败），走对了
- Django 5 默认日志级别是
WARNING，记得在LOGGING配置里把myapp设为DEBUG才能看到
真正难缠的永远不是 400，而是那些没进任何 handler 就静默 500 的情况——盯住日志输出顺序，比看文档更快定位断点。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
