Spring Boot MVC中如何在请求执行前处理HTTP请求头userId

这个需求在Spring Boot里其实有很优雅的实现方式，我给你两种常用方案，优先推荐第一种全局参数解析器的方式，能一次性搞定所有接口的userId处理，不用在每个接口里重复写逻辑。

方案一：自定义HandlerMethodArgumentResolver（推荐） #

这种方式是Spring MVC提供的扩展点，专门用来处理方法参数的解析逻辑，非常适合全局统一处理特定参数的场景。

步骤1：自定义一个标记注解（可选但更优雅） #

我们先定义一个@UserId注解，用来标记需要自动处理的参数，这样比直接判断参数名称更灵活：

@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
public @interface UserId {
}

步骤2：实现参数解析器 #

创建一个解析器类，实现HandlerMethodArgumentResolver接口，在这里完成userId的修剪和默认值设置逻辑：

@Component
public class UserIdArgumentResolver implements HandlerMethodArgumentResolver {

    // 自定义你的默认userId值
    private static final String DEFAULT_USER_ID = "default_system_user";

    @Override
    public boolean supportsParameter(MethodParameter parameter) {
        // 判断参数是否标记了@UserId注解，并且类型是String
        return parameter.hasParameterAnnotation(UserId.class) 
                && parameter.getParameterType().equals(String.class);
    }

    @Override
    public Object resolveArgument(MethodParameter parameter, 
                                 ModelAndViewContainer mavContainer,
                                 NativeWebRequest webRequest, 
                                 WebDataBinderFactory binderFactory) throws Exception {
        // 从请求头获取原始userId
        String rawUserId = webRequest.getHeader("userId");
        
        // 处理逻辑：空值设默认，非空则修剪
        if (rawUserId == null) {
            return DEFAULT_USER_ID;
        }
        String trimmedUserId = rawUserId.trim();
        return trimmedUserId.isEmpty() ? DEFAULT_USER_ID : trimmedUserId;
    }
}

步骤3：注册解析器到Spring MVC #

创建一个WebMvc配置类，把我们的解析器注册进去，这样Spring MVC就会全局使用它：

@Configuration
public class WebMvcConfig implements WebMvcConfigurer {

    private final UserIdArgumentResolver userIdArgumentResolver;

    // 构造注入解析器
    public WebMvcConfig(UserIdArgumentResolver userIdArgumentResolver) {
        this.userIdArgumentResolver = userIdArgumentResolver;
    }

    @Override
    public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
        resolvers.add(userIdArgumentResolver);
    }
}

步骤4：修改你的控制器方法 #

现在你可以直接在接口方法里用@UserId注解代替原来的@RequestHeader，参数会自动被处理：

@RestController
public class MyResource {
    @RequestMapping(value = "/heartbeat", method = RequestMethod.GET)
    public String heartbeat(@UserId String userId) {
        // 这里的userId已经是处理好的：要么是默认值，要么是修剪后的原始值
        return "Heartbeat from user: " + userId;
    }
}

方案二：使用@ControllerAdvice全局处理 #

如果你不想自定义解析器，也可以用@ControllerAdvice结合请求属性的方式来实现：

步骤1：创建全局控制器增强类 #

@ControllerAdvice
public class GlobalRequestHandler {

    private static final String DEFAULT_USER_ID = "default_system_user";

    @InitBinder
    public void preProcessRequest(NativeWebRequest request) {
        String rawUserId = request.getHeader("userId");
        // 同样的处理逻辑
        String processedUserId = rawUserId == null 
                ? DEFAULT_USER_ID 
                : rawUserId.trim().isEmpty() ? DEFAULT_USER_ID : rawUserId.trim();
        
        // 把处理后的userId放到请求属性里
        request.setAttribute("processedUserId", processedUserId, NativeWebRequest.SCOPE_REQUEST);
    }
}

步骤2：修改控制器方法 #

在接口里通过@RequestAttribute获取处理后的userId：

@RestController
public class MyResource {
    @RequestMapping(value = "/heartbeat", method = RequestMethod.GET)
    public String heartbeat(@RequestAttribute("processedUserId") String userId) {
        return "Heartbeat from user: " + userId;
    }
}

两种方案对比 #

• 方案一：更直观，专门针对参数解析，代码耦合度低，后续扩展（比如加参数校验）也更方便，推荐使用。
• 方案二：适合简单场景，但需要通过请求属性传递参数，不如方案一直接。

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