添加HttpServletRequest/Response后登录接口空指针异常排查求助

1. 修复全局异常处理器的日志输出 #

当前你的GlobalExceptionHandler仅打印固定字符串，无法获取异常的具体上下文。修改异常处理方法，输出完整的异常栈轨迹：

@ExceptionHandler(Exception.class)
public ResponseEntity<String> handleOtherException(Exception e) {
    // 打印完整栈信息，不要仅输出"Other Exception"
    e.printStackTrace();
    // 若使用SLF4J等日志框架，建议用如下方式输出
    log.error("Unexpected exception occurred", e);
    return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body("Other Exception");
}

通过完整栈轨迹，能直接定位空指针发生的类、方法和行号，这是最直接的排查手段。

2. 检查Spring MVC参数绑定逻辑 #

添加原生Servlet API入参后触发异常，大概率出在请求参数解析阶段：

• 核对doLogin方法签名，比如是否同时混用@RequestBody与表单参数，或入参顺序不符合Spring MVC的解析规则；
• 排查项目中是否自定义了HandlerMethodArgumentResolver，这类自定义解析器可能在处理HttpServletRequest/HttpServletResponse时出现空指针。

3. 开启Spring MVC调试级日志 #

在日志配置文件（如application.yml或logback.xml）中开启Spring MVC核心模块的DEBUG日志：

logging:
  level:
    org.springframework.web: DEBUG
    org.springframework.web.servlet: DEBUG

这些日志会输出请求处理的全流程细节，包括参数解析、处理器映射的每一步，能清晰看到异常触发的环节。

4. 本地调试加断点 #

若本地可复现问题，给以下关键位置加断点跟踪：

• DispatcherServlet的doDispatch方法：这是请求处理的入口，跟踪请求走到哪一步抛出异常；
• 自定义GlobalExceptionHandler的异常处理方法：捕获异常后查看e.getStackTrace()，直接定位异常根源；
• 项目中的拦截器（Interceptor）：在preHandle方法加断点，确认是否在进入Controller之前就触发了空指针。

5. 排查版本兼容问题 #

如果近期升级了Spring Boot/Spring MVC版本，或更换了Servlet容器（如Tomcat切换为Jetty），可能存在原生Servlet API参数注入的兼容问题。可临时切换回之前正常的版本验证。

内容的提问来源于stack exchange，提问作者meimaymay