Flask全局捕获自定义异常APIException需继承Exception类、在app实例化后注册@app.errorhandler(APIException)，异常类须显式定义status_code等属性，handler返回jsonify({“error”:{“code”:e.error_code,“message”:e.message}})。
Flask怎么全局捕获自定义异常APIException
直接用 @app.errorhandler 注册自定义异常类即可，但必须确保该异常类是 Exception 的子类，且在注册前已定义。Flask 只认继承链上的异常类型，不支持字符串匹配或动态类名查找。
常见错误现象：抛出 APIException 后返回 500 而非预期状态码，多半是类没被 import 进注册作用域，或者用了 @app.errorhandler(404) 这类状态码注册方式去捕获自定义异常——它只对 HTTP 状态码生效，对自定义类无效。
- 把
APIException定义在独立模块（如exceptions.py），避免循环 import - 在创建
Flask实例后、调用app.run()前完成@app.errorhandler(APIException)注册 - 如果用工厂模式（
create_app()），注册逻辑必须放在工厂函数内部，不能写在模块顶层
APIException 怎么设计才能适配 errorhandler 自动提取字段
Flask 的 @app.errorhandler 回调函数接收一个异常实例，后续组装 JSON 全靠你从这个实例上取属性。所以 APIException 必须自带 status_code、error_code、message 这类可读属性，而不是靠 __str__() 拼接。
典型反例：有人把所有信息塞进 super().__init__(f"{code}:{msg}")，结果 handler 里只能拿到一串字符串，没法拆出状态码或业务码。
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 构造函数显式接收
message、status_code=400、error_code="VALIDATION_ERROR"等参数 - 给每个属性加默认值，比如
status_code默认 400，避免漏传导致 500 - 不要重写
__str__或__repr__来承载关键数据，它们只用于调试输出
class APIException(Exception):
def __init__(self, message, status_code=400, error_code="UNKNOWN_ERROR"):
super().__init__(message)
self.message = message
self.status_code = status_code
self.error_code = error_code
全局 handler 怎么返回标准 JSON 格式且不破坏原有 404/500 处理
同一个 Flask 应用里可以注册多个 @app.errorhandler，它们互不干扰。你要做的是：为 APIException 单独写一个 handler，再保留 Flask 默认的 404/500 行为（或另写 handler 覆盖），别试图在一个函数里 if-else 分流所有异常类型——难维护还容易漏。
性能影响很小，因为 errorhandler 是装饰器注册，不是每次请求都扫描；但要注意：如果你在 handler 里又 raise 新异常（比如日志失败），可能触发二次错误处理，导致响应体混乱。
- handler 函数签名固定为
def handle_api_exception(e: APIException):，参数名无所谓，但类型注解能帮 IDE 提示属性 - 统一用
jsonify({ "error": { "code": e.error_code, "message": e.message } })返回，别用make_response手动设 status——jsonify第二个参数就是 status_code - 已有
@app.errorhandler(404)不会影响APIExceptionhandler，除非你手动 raiseNotFound()（那是 Werkzeug 异常）
为什么有些 APIException 抛出后没进 handler，而是进了 500 页面
最常见原因是异常没被 Flask 的异常传播机制“看到”——比如你在 before_request 里抛了 APIException，但没配置 @app.errorhandler 在同一 app 实例上；或者用了蓝本（Blueprint），却把 handler 注册在了蓝本而非 app 上。
另一个隐蔽坑：异步视图（async def）中抛出的异常，Flask 2.0+ 才原生支持捕获，旧版本会直接崩掉 worker。还有就是 Gunicorn/uWSGI 配置了 catch_exceptions=True，会提前吞掉异常。
- 检查
APIException是否真的被 raise 出来了（加个 print 或 log），而不是被 try-except 吃掉了 - 确认 handler 注册在和视图相同的
Flask实例上；蓝本里注册要用@bp.errorhandler(APIException)，且需app.register_blueprint(bp) - 生产环境关掉
debug=True，否则 500 页面会掩盖真实错误路径
