Flask中@app.errorhandler(500)不捕获未处理异常，需用@app.errorhandler(Exception)兜底并置于末尾；debug=True时所有errorhandler失效；统一JSON错误响应须为jsonify(...), status形式，并区分HTTP状态码与业务code。
Flask 中用 @app.errorhandler 捕获 500 错误不生效？
默认情况下，@app.errorhandler(500) 只捕获由 Flask 主动抛出的 HTTPException 子类（比如 abort(500)），而未捕获未处理的 Python 异常（如 ZeroDivisionError、KeyError）。这类异常会直接触发 Werkzeug 的调试页面（开发环境）或 500 响应但无自定义 JSON 格式。
真正起作用的是 @app.errorhandler(Exception) —— 它能兜住所有未被捕获的异常，但要注意它必须在所有其他 @app.errorhandler 之后注册，否则会覆盖更具体的处理器。
- 不要写
@app.errorhandler(500)试图捕获所有崩溃，它做不到 - 务必把
@app.errorhandler(Exception)放在最末尾，避免拦截NotFound、BadRequest等已有语义的异常 - 开发时开启
debug=True会绕过所有errorhandler，必须设为debug=False才能测试真实行为
如何让所有错误都返回统一 JSON 格式（含 status code）
核心是：对每种错误类型分别注册 @app.errorhandler，并在响应中显式设置 status 和 Content-Type: application/json。不能只靠 jsonify()，它默认返回 200。
示例写法：
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
立即学习“Python免费学习笔记（深入）”；
@app.errorhandler(404)
def not_found(e):
return jsonify({"code": 404, "msg": "Resource not found"}), 404
@app.errorhandler(500)
def internal_error(e):
return jsonify({"code": 500, "msg": "Internal server error"}), 500
@app.errorhandler(Exception)
def unhandled_exception(e):
app.logger.exception("Unhandled exception")
return jsonify({"code": 500, "msg": "Server error"}), 500
-
jsonify(...), 404这种元组形式才能正确设置状态码；仅jsonify(...)返回 200 - 如果用了 Flask-RESTful，它的
Api类自带handle_error，优先走它的机制，别重复注册全局 handler - 确保返回值是
Response对象或可被 Flask 自动转为 Response 的结构（如元组）
为什么 try/except 在路由里写一堆很危险
手动在每个 @app.route 函数里加 try/except 不仅重复、易漏，还会掩盖原始异常堆栈，不利于定位问题。更重要的是：它无法捕获装饰器中抛出的异常（比如 @login_required 内部失败）、before_request 中的异常，以及响应生成后、发送前的异常（如 JSON 序列化失败）。
- 业务逻辑层该抛异常就抛，不要提前吞掉——交给全局 handler 统一收口
- 若需在某路由中特殊处理某个异常（如
ValidationError返回 400），可在该路由内try/except后主动调用abort(400)，再由对应@app.errorhandler(400)格式化 - 全局 handler 中尽量避免再抛异常，否则可能触发递归 500
生产环境必须加的日志与降级细节
光返回 JSON 不够。没日志，线上出错等于瞎子；没降级，一个异常可能拖垮整个服务。
- 在
@app.errorhandler(Exception)里务必调用app.logger.exception(msg)，而不是app.logger.error()，否则丢堆栈 - 避免在 handler 中做耗时操作（如发邮件、调外部 API），它们可能阻塞响应或引发新异常
- 如果用了 Gunicorn/UWSGI，确保
capture_output=True或日志重定向配置正确，不然app.logger输出可能丢失 - 考虑加个开关（如环境变量
FLASK_JSON_ERRORS=1），开发时保留 HTML 错误页便于调试，生产强制 JSON
最常被忽略的一点：JSON 错误响应体里的 code 字段，别和 HTTP 状态码混用。比如业务错误（用户余额不足）该返回 {"code": 1001, "msg": "..."}, 400，而不是强行用 500 —— 状态码表协议层，code 表业务语义，两者职责不同。
