process_exception方法仅在DEBUG=False时生效，且需满足ALLOWED_HOSTS配置正确、中间件继承MiddlewareMixin并正确注册等条件；它专用于捕获视图未处理异常，返回HttpResponse子类响应，避免在API场景误用而应优先采用DRF的EXCEPTION_HANDLER。
process_exception 方法只在 DEBUG=False 时生效
Django 的 process_exception 不会在 DEBUG=True 下触发，这是最常被忽略的前提。你写好了中间件、注册了、也抛了异常，但前端看到的还是 Django 默认的黄色调试页——大概率是这个原因。
必须同时满足以下条件，process_exception 才会执行：
-
DEBUG=False（settings.py 中） -
ALLOWED_HOSTS配置正确（否则请求根本进不来，更不会走到异常处理） - 中间件类继承
MiddlewareMixin，且重写了process_exception - 该中间件在
MIDDLEWARE列表中位置靠前（建议放在SecurityMiddleware之后、SessionMiddleware之前）
不要用 __call__ 包裹整个请求流来捕获 Exception
有些示例用 __call__ + try/except 拦截所有异常，看似简单，但它会吞掉视图未返回 Response 的情况（比如忘记 return）、绕过 Django 的响应中间件（如 ContentLengthMiddleware），还可能干扰 DRF 的异常链路。
真正干净的做法是只用 process_exception：它只在视图函数内部抛出未捕获异常时调用，不影响正常流程，也和 DRF 的 EXCEPTION_HANDLER 兼容。
立即学习“Python免费学习笔记（深入）”；
示例错误写法（避免）：
def __call__(self, request):
try:
return self.get_response(request)
except Exception as e:
return JsonResponse({'code': -1, 'msg': str(e)}, status=500)
正确写法（推荐）：
from django.middleware.common import MiddlewareMixin
from django.http import JsonResponse
class ExceptionMiddleware(MiddlewareMixin):
def process_exception(self, request, exception):
return JsonResponse({'code': -1, 'msg': 'Server error'}, status=500)
DRF 项目优先用 EXCEPTION_HANDLER 而非中间件
如果你用了 Django REST Framework，EXCEPTION_HANDLER 是更精准的选择：它只处理 API 视图抛出的异常，天然支持 Response 对象，能区分 ValidationError、NotFound 等语义化异常，且不干扰 HTML 视图。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
配置方式很简单，在 settings.py 中：
REST_FRAMEWORK = {
'EXCEPTION_HANDLER': 'myapp.exceptions.custom_exception_handler',
}
对应函数示例：
from rest_framework.views import exception_handler
from rest_framework.response import Response
def custom_exception_handler(exc, context):
response = exception_handler(exc, context)
if response is None:
return Response({'code': -1, 'msg': 'Internal server error'}, status=500)
response.data = {'code': response.status_code, 'msg': response.data.get('detail', 'Error')}
return response
注意：这个函数不会处理 DatabaseError 或裸 Exception，需要你自己补全逻辑。
中间件里别 raise 新异常，也别 return None
process_exception 返回 None 表示“我不处理，交给下一个中间件或 Django 默认逻辑”，结果就是 500 HTML 页面——这在 API 场景下完全不可接受。
同样，如果在里面 raise ValueError("xxx")，Django 会再次触发 process_exception，形成循环，最终仍 fallback 到默认 500 页。
务必确保每种异常分支都返回一个 HttpResponse 子类实例（如 JsonResponse、HttpResponse）：
- 业务异常（如
BusinessException）→ 返回 400 + 自定义 JSON - 数据库异常（
DatabaseError）→ 记录日志 + 返回 500 - 其他异常（
Exception）→ 统一兜底 500，但别暴露堆栈
最后一点容易被忽略：生产环境永远不要把 str(exception) 或 traceback.format_exc() 直接返回给前端，哪怕只是开发阶段测试，也要养成先打日志、再返回泛化提示的习惯。
