Python网站全局异常捕获核心是统一拦截未处理异常，转换为用户友好提示并记录原始错误供排查；Flask用@errorhandler、Django用自定义中间件，均需区分环境、结构化响应、分层处理错误。
Python网站项目实现全局异常捕获与友好提示，核心在于**统一拦截未处理异常，转换为用户可读的响应，并记录原始错误供排查**。不同框架方案不同，但思路一致：不把技术细节暴露给前端，也不让异常中断服务。
Flask 中全局异常捕获（推荐）
Flask 通过 @app.errorhandler 注册异常处理器，覆盖 500 错误及自定义异常：
- 对所有未捕获的 Exception 统一处理，返回 JSON 或渲染友好页面
- 区分开发/生产环境：开发时显示 traceback（方便调试），生产时只返回简明提示 + 错误 ID
- 配合日志模块记录完整异常信息（含时间、路径、请求参数、堆栈），便于后续定位
示例片段：
@app.errorhandler(500)
def internal_error(error):
error_id = str(uuid.uuid4())[:8]
app.logger.error(f"[{error_id}] 500: {request.url} | {str(error)}", exc_info=T
rue)
if app.debug:
return render_template("error_500.html", error=str(error), traceback=traceback.format_exc())
else:
return render_template("error_500.html", error_id=error_id, message="服务器开小差了，请稍后再试~")
@app.errorhandler(Exception)
def unhandled_exception(e):
捕获所有未被其他 handler 处理的异常
return internal_error(e)
rue)
if app.debug:
return render_template("error_500.html", error=str(error), traceback=traceback.format_exc())
else:
return render_template("error_500.html", error_id=error_id, message="服务器开小差了，请稍后再试~")
Django 中全局异常处理（中间件方式）
Django 更适合用 自定义中间件 实现全链路异常拦截，比只靠 handler500 更灵活：
- 在 process_exception 方法中捕获视图抛出的异常
- 避免模板 500 页面无法加载的问题（中间件在响应生成前介入）
- 可结合 Django 的 messages framework 向用户推送提示，或返回 JsonResponse
关键点：中间件需注册在 MIDDLEWARE 配置靠后位置（确保已过身份验证、CSRF 等前置中间件）。
统一错误响应结构（前后端协作基础）
无论用什么框架，建议约定标准错误格式，例如：
{
"code": 500,
"message": "系统繁忙，请稍后重试",
"detail": "error_id: abc12345" // 仅生产环境提供，用于查日志
}
- 前端根据 code 做差异化处理（如 401 跳登录，403 提示无权限，500 显示 toast）
- 后端所有接口（包括 REST API 和模板视图）尽量复用同一套错误包装逻辑
- 避免在业务代码里零散写
try...except...return error_json，应集中到装饰器或基类中
补充建议：别忽略这些细节
- 数据库连接失败、Redis 超时等外部依赖异常，要单独捕获并降级处理（如返回缓存数据或默认值）
- 用户输入引发的 ValidationError、ValueError 等，应归为 400 类错误，提示“请检查填写内容”，而非 500
- 日志中记录 request.args / request.json / session.get('user_id') 等上下文，但注意脱敏敏感字段（如密码、token）
- 前端 JS 报错也可通过 Sentry 或自建上报接口收集，和后端错误 ID 关联分析
基本上就这些。不复杂但容易忽略的是：异常处理不是“兜底就行”，而是要分层——输入校验拦截 400、业务规则拦截 403/409、系统故障拦截 500，并各自给出恰当反馈。做好这一步，用户体验和运维效率都会明显提升。
