前端调接口，Network 里红了一片 500，后端日志却看不出哪行报错。500 是服务器内部错误，最抽象也最常见，只能顺着它往下查。

先把错误码看清楚

500 是通用内部错误，502 是网关拿到后端无效响应，504 是网关等后端超时。三者很容易混。看到 500 先确认后端容器是不是活着，请求有没有进到业务代码里。

后端自己该做的

  • 打完整堆栈：异常一定要输出完整 stack trace，别只 catch 打一句 getMessage，那样常常只有一句 null。
  • 加全局异常处理：把未捕获异常统一拦下来，返回结构化信息和 traceId，前端好拿这个 id 去对日志。
  • 盯空指针：线上 500 里空指针占很大比例，入参没校验、Optional 忘了取都会中招。

几个典型触发原因

数据库连接池打满、慢查询把连接占死，表现为突发的 500；序列化时对象里有循环引用，Jackson 会直接抛异常；返回对象里字段是 null 又配了非空校验；还有类是依赖包版本冲突导致的 NoSuchMethodError，打包部署后尤其常见。

排查顺序

先在网关看请求有没有到后端，再翻应用日志按时间点找异常，接着看数据库和下游依赖状态，最后确认是不是刚发版引入的。能靠 traceId 串起来会快很多。

顺带提一句，上线后配个告警，几分钟内 500 超过阈值就通知值班。很多故障是用户先发现的，就是因为没人盯这个指标。告警配好了，半夜能少爬起来几次。

500 报出来不可怕，可怕的是接口把异常吞了，日志只有一句系统异常。把全局异常和链路追踪做扎实，这类问题才能几分钟定位，而不是靠猜。