网关热部署错误码关键在于异常结构化与动态生效：errorcode需为枚举含code/httpstatus/messagetemplate，businessexception构造时注入上下文并保留cause，errorwebexceptionhandler按类型+错误码双路由响应，通过spi加载独立异常模块实现热更新。
网关下热部署错误码，关键不在“热部署”本身，而在于让错误码能随业务逻辑变化即时生效、前后端一致、排查可追溯。这需要把自定义运行时异常设计成可携带上下文、可嵌套传递、可被统一解析的结构化载体——也就是构建一条有语义、有层次、有源头的异常链。
错误码必须绑定到异常实例，而非静态常量
把 ErrorCode 写成枚举或接口常量，再在 catch 里硬编码 throw new BusinessException(ErrorCode.ORDER_TIMEOUT, "超时")，看似规范，实则埋雷：一旦错误码含义变更或新增场景，必须改代码+重启网关，无法热更新。正确做法是让 ErrorCode 成为异常对象的不可变属性，并通过构造器注入上下文信息：
- 定义 ErrorCode 枚举时，每个值包含 code、httpStatus、messageTemplate（如 “订单 %s 超时”）
- 自定义异常类（如 BusinessException）在构造时接收 ErrorCode + 占位参数（如 orderNo），内部立即格式化 message，并缓存原始参数供后续解析
- 这样错误码逻辑封装在异常创建环节，只要新异常类加载进 JVM（热部署时可触发），新规则就自动生效
异常链必须保留 cause，确保根因不丢失
网关常见错误来源包括路由失败（Connection refused）、下游服务返回 5xx、鉴权拦截、限流熔断等。若在 Filter 或 GlobalFilter 中捕获异常后只抛新异常却不传 cause，原始堆栈和状态就彻底丢失：
- ❌ 错误示例：
throw new BusinessException(ErrorCode.SERVICE_UNAVAILABLE, "服务暂不可用"); - ✅ 正确示例：
throw new BusinessException(ErrorCode.SERVICE_UNAVAILABLE, "服务暂不可用", originalException); - 这样 ExceptionChain 会完整保留从 Netty 连接异常 → WebClient 调用失败 → 网关包装异常的全路径，日志中一眼可见根因是 Connection refused 还是 TimeoutException
网关异常处理器需按异常类型+错误码双重路由响应
Spring Cloud Gateway 是响应式栈（WebFlux），不能用 @ControllerAdvice。必须实现 ErrorWebExceptionHandler，并在 handle 方法中做两层判断：
- 先识别异常类型（BusinessException / SystemException / ExternalServiceException），决定是否属于业务可控错误
- 再提取其 errorCode 属性，匹配预设的 HTTP 状态码映射表（如 ErrorCode.SERVICE_UNAVAILABLE → 503，ErrorCode.AUTH_FAILED → 401）
- 最终响应体统一为 { "code": "ORDER_NOT_FOUND", "status": 404, "message": "订单 XXX 不存在" }，前端无需解析多种格式
热部署生效依赖类加载隔离与异常注册机制
要让新错误码逻辑在不重启网关前提下生效，需配合以下两点：
- 将 ErrorCode 枚举和自定义异常类打包为独立模块（如 common-exception-starter），网关通过 SPI 或 Spring Factories 方式动态加载其实现
- 在网关启动时，扫描 classpath 下所有实现了
ErrorCodeProvider接口的 Bean，将其注册进全局错误码管理中心；热部署时重新触发扫描并刷新缓存 - 避免直接在网关模块里硬写枚举，否则每次改码都要编译发布
