spring boot中controlleradvice捕获异常后http状态码未变，主因是@exceptionhandler未显式返回responseentity或@responsestatus注解；网关层不自动转换后端5xx为4xx，需通过header或globalfilter干预；自定义异常应优先用@responsestatus而非getstatus()方法。
Spring Boot里ControllerAdvice捕获异常但HTTP状态码没变
常见现象是：明明在@ExceptionHandler里写了response.setStatus(400)或return ResponseEntity.badRequest().build()，前端收到的仍是500。根本原因是Spring MVC默认把未处理的RuntimeException兜底转成500，而你的@ExceptionHandler方法如果没显式返回ResponseEntity或加@ResponseStatus，就等于没真正接管响应状态。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 优先用
@ResponseStatus(code = HttpStatus.BAD_REQUEST, reason = "xxx")修饰异常类本身，比在ControllerAdvice里写一堆@ExceptionHandler更轻量、更可靠 - 如果必须动态决定状态码（比如根据异常字段值），就用
ResponseEntity>返回，别碰HttpServletResponse——它绕过Spring的响应生命周期，容易和消息转换器冲突 - 确保
ControllerAdvice类被@Component扫描到，且包路径覆盖了实际抛异常的Controller；常见坑是Advice放在启动类同级目录外，导致不生效
网关层（如Spring Cloud Gateway）对后端5xx异常的默认透传问题
网关不会自动把后端返回的500重写成4xx，哪怕后端其实抛的是IllegalArgumentException。它只做转发，原始状态码原样透出。这会让前端无法区分“服务不可用”和“参数错”，也违背REST语义。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 在网关的
GlobalFilter里拦截WebClientResponseException，检查响应体是否含业务错误码字段（如"code": "VALIDATION_FAILED"），再用ServerHttpResponse.setStatusCode()覆盖状态码 - 避免在网关做复杂JSON解析——性能差还容易因字符编码/流关闭时机出错；推荐后端统一用固定header（如
X-App-Status: 400）传递意图，网关只读header改状态 - 注意网关超时配置（如
spring.cloud.gateway.httpclient.connect-timeout）可能掩盖真实异常：后端卡住时网关先报504，你再怎么改500逻辑都收不到
自定义异常类里getStatus()方法被忽略的原因
有人给异常类加了public HttpStatus getStatus()，指望Spring自动识别，结果没用。Spring MVC只认@ResponseStatus注解或ResponseEntity返回值，不反射调用异常对象的方法。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 删掉无用的
getStatus()，改用@ResponseStatus注解该异常类，或者让异常实现ResponseStatusException接口（Spring 5.2+） - 如果异常来自三方SDK（没法改源码），就在
ControllerAdvice里用instanceof判断类型，再手动映射到对应HttpStatus - 别在异常构造时硬编码状态码字符串（如
new MyException("400")），字符串匹配易错且难维护；用枚举或常量类集中管理映射关系
Feign Client调用下游失败时状态码丢失
Feign默认把所有HTTP错误响应（4xx/5xx）都包装成FeignException，原始状态码藏在feignResponse.status()里，但Spring Cloud OpenFeign的fallback机制不自动暴露这个值，导致上层拿到的永远是500。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 写fallback类时，不要只抛新异常，而是从
FeignException里提取status()，再用ResponseEntity.status(status).body(...)返回 - 启用
feign.codec.ErrorDecoder自定义实现，在decode()方法里直接根据response.status()构造带正确状态码的异常，比fallback更早介入 - 注意
feign-spring-cloud-starter版本差异：2.x和3.x的ErrorDecoder签名不同，低版本需继承Default类，高版本直接实现接口
最麻烦的其实是异常分类边界——比如数据库唯一约束失败，后端抛DataIntegrityViolationException，该映射成409 Conflict还是400 Bad Request？这没有技术标准，只有业务约定。一旦定错，网关和前端的错误处理逻辑就得全量返工。
