关键在于通过结构化异常流转实现动态转化：生成器抛出带语义的GeneratorException，防腐层封装为StandardErrorPayload并抛出ContractualFailureException，契约处理器依热更新映射表输出标准化错误响应。
关键不在“加 try-catch”，而在于把生成器内部异常作为信号，注入上下文、绑定错误码、交由统一契约层输出——整个过程不依赖硬编码捕获，而是靠结构化异常流转实现动态转化。
让生成器抛出的异常自带语义和上下文
生成器（如 OpenAPI Schema 解析器、规则引擎执行器、DSL 编译器）出错时，不能直接 throw new RuntimeException("解析失败")。必须统一包装为可识别的运行时异常类型，例如：
- 继承自 GeneratorException（非受检），并强制构造时传入标准 ErrorCode 枚举值
- 构造器接收原始 cause、当前输入片段（如 YAML 片段、表达式字符串）、traceId、租户 ID 等轻量上下文字段
- ErrorCode 中定义 httpStatus、code 数字、messageTemplate（如 "第{line}行：{reason}"），确保后续可格式化、可审计、可国际化
在防腐层拦截点做“无业务逻辑”的异常转译
网关防腐层（如 GatewayFilter 或自定义 RouterFunction）中不写具体错误处理逻辑，只做两件事：
- 用 try-catch 包裹生成器调用，但 catch 块里不做日志、不返回、不重试，只做一件事：将原始异常 + 上下文封装为 StandardErrorPayload 对象
- 通过 ThreadLocal 或 Reactor Context 注入当前请求的防腐策略 ID、版本号、客户端类型等元信息，供后续契约层决策响应格式
- 最终 throw 新异常（如 ContractualFailureException），该异常持有了全部可序列化字段，且实现了 getErrorCode() 接口
由统一契约处理器完成最终标准化输出
全局错误处理器（如 Spring Cloud Gateway 的 ErrorWebExceptionHandler）负责最终落地：
- 判断异常是否属于 ContractualFailureException 或其子类
- 反射调用 getErrorCode()，查热加载的映射表（如从 Nacos 加载的 error-code-routing.json）获取对应 HTTP 状态码、响应体结构（JSON/XML）、是否需触发告警
- 根据客户端 Accept 头或防腐策略 ID，选择返回标准 JSON 错误体（code/message/traceId）或兼容旧版的 XML 格式，甚至降级为纯文本提示
- 全程保留原始 cause 链，确保日志中能展开看到：YAML 解析异常 → SchemaValidator 抛出 → 防腐层包装 → 契约处理器渲染
支持运行时变更提示文案与状态码
错误码映射表本身是可热更新的配置项，不重启即可生效：
- 映射表结构示例：{"ORDER_INVALID": {"httpStatus": 400, "message": "订单参数不合法，请检查 {field} 字段"}}
- 修改 message 模板后，下次请求遇到该错误码，自动使用新文案；改 httpStatus 后，响应状态码立即变化
- 配合 SPI 加载机制，甚至可按租户 ID 加载不同提示包，实现多租户差异化提示
