1. 从一次“取不了Request”的求助说起1.1 面试官为什么总把“几种方法”挂在嘴边一次组里来了个新人改一个老项目需求不复杂在操作日志里记录当前登录用户的IP。Controller里他轻车熟路地拿了HttpServletRequest但日志记录逻辑写在Service层Service方法签名里压根没有request参数。他跑过来问我“在Service里怎么拿Request对象网上答案一搜好几套有的说参数注入有的说RequestContextHolder有的说直接Autowired到底哪个是对的”这个问题其实也是SpringBoot面试里的常见题问法通常是“SpringBoot有几种获取Request对象的方法”。不少面试者能答出“Controller方法参数注入”和“RequestContextHolder”但再往深了问Filter和Interceptor里能不能拿HandlerMethodArgumentResolver又是干嘛的异步线程里为什么拿不到很多人就卡住了。“几种方法”这四个字面试官真正想考察的并不是你背了几个API而是你对SpringMVC请求处理链路的理解。Request对象从Servlet容器进入DispatcherServlet之后Spring在链路的不同节点都留有入口你的方法就藏在不同的入口里。1.2 Request在SpringMVC里到底经过了哪些入口要理解这个问题先想清楚Servlet层的事情。Servlet规范定义了HttpServletRequest由Servlet容器Tomcat是SpringBoot默认容器创建容器把请求包装成Request对象然后在Filter链里传递最终交给Servlet处理。SpringBoot里的DispatcherServlet本质上就是一个Servlet它接收到的Request对象和你在Filter里看到的是同一个东西可能被包装过一次或多次。到了DispatcherServlet内部SpringMVC又做了一层加工DispatcherServlet根据URL找HandlerMapping定位到具体的方法再把Request对象交给HandlerAdapterHandlerAdapter内部会调用一组HandlerMethodArgumentResolver把Request对象里的header、parameter、body、cookie等内容解析出来绑定到Controller方法的参数上。所以“获取Request对象”在SpringBoot里其实不是一个单一入口而是Spring在请求生命周期的多个环节都暴露了入口Controller方法签名里声明参数由参数解析器注入整个请求处理线程里通过RequestContextHolder拿静态绑定Filter链和HandlerInterceptor的preHandle方法中直接拿到Request自定义HandlerMethodArgumentResolver在进入Controller之前把你想绑定的东西做好容器里使用request作用域的Bean让Spring内部帮你注入代理对象。这五类入口对应了从Servlet层到SpringMVC方法调用的全过程。接下来我按实际使用频率和场景逐个拆开讲。2. 常规写法方法参数注入在Controller里直接拿2.1 最简单的声明式获取最常用的方式没有之一就是在Controller方法里直接声明HttpServletRequest参数。SpringMVC内置的ServletRequestMethodArgumentResolver看到方法参数类型是HttpServletRequest会直接把当前的Request对象塞进去。RestController RequestMapping(/api/user) public class UserController { GetMapping(/info) public ResultUserInfo info(HttpServletRequest request, RequestParam Long id) { String token request.getHeader(Authorization); String ip getClientIp(request); UserInfo user userService.queryById(id); return Result.ok(user); } }这方法写起来最省事也不需要额外引入任何东西。你可以在方法体里读取header、读取请求参数、读取request的attribute还可以通过request.getSession()拿到会话对象。同时也可以配合RequestParam、RequestHeader、PathVariable这些注解拿具体的数据而Request本身作为“兜底”用于处理一些注解不太好表达的场景。2.2 为什么说能拿参数就别在Service里翻Request这里给个建议虽然参数注入是拿Request最直白的方式但在Controller里拿到Request之后不要顺手把整个对象传进Service。原因有三个第一耦合度高。Service层一旦出现HttpServletRequest说明业务逻辑和Web容器绑定了以后如果你想把这个Service复用到定时任务、消息队列消费里它就会成为一个障碍因为那些场景根本没有Request。第二不易测试。Service方法依赖Request对象后单元测试要构造一个完整的MockRequest才能跑成本凭空高出一截。第三参数语义不清晰。Service方法更好的入参是“业务需要的数据”而不是“包含很多数据的容器对象”。比如登录用户ID、客户端IP、链路ID这些你可以在Controller层抽成普通的Java参数传下去。我实际见到很多老项目里Service层到处是request.getParameter(xxx)结果后续加一个定时任务导出报表功能只能再写一套“无Request版本”的逻辑代码越来越难维护。所以参数注入只建议用在Controller层隔离组合交给下一层处理。2.3 配合注解拿参数的常见操作除了直接拿RequestSpringMVC还给了几个更精准的注解很多场景下甚至不需要Request对象GetMapping(/order) public ResultOrder getOrder(RequestHeader(X-User-Id) Long userId, RequestParam(value orderNo, required true) String orderNo, CookieValue(name SESSION, required false) String sessionId) { // 直接使用userId、orderNo、sessionId }RequestHeader拿单个请求头RequestParam拿URL参数或表单参数CookieValue拿CookieRequestBody拿JSON对象。这是主流写法也是SpringBoot里声明式获取参数的标准姿势。只有当你要读取所有Header做遍历、把请求流转成字符串再做业务解析、或者从attribute里取拦截器放进去的临时标记时才真正需要拿到HttpServletRequest对象本身。写在这里是想提醒大家方法参数注入是最常用的“获取Request对象的方法”但在大多数Controller方法里我们并不真的需要Request需要的只是它里面的业务数据。把数据声明出来比传递整个Request更优雅。3. 脱离ControllerRequestContextHolder的搬运法3.1 Service层和工具类里应该怎么写回到一开始那个新人的问题Service方法里没有HttpServletRequest参数但就是要拿客户端IP怎么办Spring提供了一个静态工具类RequestContextHolder它可以在当前请求处理线程内取到绑定的ServletRequestAttributes再从里面拿Request。标准写法如下public class RequestContextUtil { public static HttpServletRequest getRequest() { RequestAttributes attributes RequestContextHolder.getRequestAttributes(); if (attributes instanceof ServletRequestAttributes) { return ((ServletRequestAttributes) attributes).getRequest(); } throw new IllegalStateException(当前线程没有绑定Request请确认是否在HTTP请求线程中调用); } public static String getClientIp() { HttpServletRequest request getRequest(); String ip request.getHeader(X-Forwarded-For); if (ip null || ip.isEmpty()) { ip request.getRemoteAddr(); } return ip; } }用的时候就是在Service里直接调Service public class AuditLogService { public void record(String operation) { HttpServletRequest request RequestContextUtil.getRequest(); String ip RequestContextUtil.getClientIp(); auditLogMapper.insert(new AuditLog(operation, ip)); } }这样Service方法的签名保持干净业务代码又确实拿到了Request信息是很多项目在做的折中方案。3.2 ThreadLocal原理为什么同一线程内都能拿到RequestContextHolder的实现核心是一个ThreadLocalpublic abstract class RequestContextHolder { private static final ThreadLocalRequestAttributes requestAttributesHolder new NamedThreadLocal(Request attributes); }DispatcherServlet在处理请求时通过RequestContextFilter或者RequestContextListener把当前的ServletRequestAttributes放进去请求处理结束再清理。于是只要是同一个线程内的代码不管是在Controller层、Service层还是某个工具类里都能通过这个静态变量取到当前请求的上下文。这正是它和“方法参数注入”最大的区别方法参数注入是Spring在调用方法时把Request塞给指定的参数是“显式传递”RequestContextHolder是Spring把Request“挂”在了当前线程上你需要时自己取是“隐式访问”。有一点要注意RequestContextHolder.getRequestAttributes()返回的是RequestAttributes接口不是HttpServletRequest。实际类型往往是ServletRequestAttributes必须做一次类型判断和强转。有的从RequestContextHolder拿request不看类型就强转遇到自定义的RequestAttributes实现时会抛ClassCastException。上面代码里用了instanceof判断就是防这个。3.3 使用RequestContextHolder的几个强制注意点RequestContextHolder不是万能的使用时有几个必须记住的注意事项只能在处理HTTP请求的线程里调用。Async异步方法、线程池任务、定时任务、MQ消费者中getRequestAttributes()返回null。这几乎是新手踩得最多的坑后面第5节详细说。不要在请求处理完之后保存Request对象。请求结束线程绑定会被清理Request对象本身也会被容器回收这时候再访问里面的数据是不可靠的。如果方法可能在非Web场景被复用建议先判断attributes null。比如同一个Service方法既被Controller调用又被定时任务调用直接调用getRequest()就会抛异常做空判断能避免线上告警。慎用request.getSession()。在高并发场景下顺手调getSession()会创建会话并可能带来会话锁竞争不是所有请求都需要会话。跨线程传递时要格外小心下文会专门讲。4. 请求链路里的其他入口Filter、Interceptor、自定义参数解析器4.1 Filter在进入SpringMVC之前就拿到RequestFilter是Servlet规范定义的组件执行时机比DispatcherServlet更早。SpringBoot里注册一个自定义Filter很简单Component public class TraceFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest httpRequest (HttpServletRequest) request; String traceId httpRequest.getHeader(X-Trace-Id); if (!StringUtils.hasText(traceId)) { traceId UUID.randomUUID().toString().replace(-, ); } httpRequest.setAttribute(traceId, traceId); chain.doFilter(request, response); } }这里的request参数类型是ServletRequest在实际HTTP请求场景中就是HttpServletRequest所以强转是安全的。Filter适合做链路追踪、跨域处理、请求日志、接口签名校验这类需要在SpringMVC介入之前完成的事情。这里要提醒一个细节如果你使用了Spring的OncePerRequestFilterSpringBoot常见的写法它保证了同一个请求只过一遍Filter避免转发等情况下重复执行。做登录鉴权、请求日志这种操作能用OncePerRequestFilter就尽量用它。Component public class JwtAuthFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String token request.getHeader(Authorization); // 校验token... filterChain.doFilter(request, response); } }4.2 Interceptor在每个请求进入Handler前处理HandlerInterceptor是SpringMVC提供的切面接口它位于DispatcherServlet之后、Controller方法之前比Filter更接近业务层。它的preHandle方法自带HttpServletRequest参数public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } String token request.getHeader(Authorization); if (!StringUtils.hasText(token)) { response.setStatus(401); return false; } Long userId jwtService.parseUserId(token); request.setAttribute(currentUserId, userId); return true; } }注册Interceptor通常配合WebMvcConfigurerConfiguration public class WebMvcConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/login, /api/register); } }Interceptor中最重要的一个特征preHandle返回false可以终止请求而Filter做不到这么细粒度的业务阻断当然Filter里也能直接返回响应但Interceptor对HandlerMethod有感知能判断是不是真正的处理器方法。在Interceptor里你既可以直接拿Request也能通过request.setAttribute把处理结果存给后续的Controller使用Controller里再用HttpServletRequest.getAttribute取出来。4.3 自定义ArgumentResolver把“公共参数”变成方法参数如果你觉得每个方法手写“从Request取当前登录用户”这段代码太重复可以把这一步交给HandlerMethodArgumentResolver。它才是SpringMVC参数绑定的底层机制。public class CurrentUserArgumentResolver implements HandlerMethodArgumentResolver { Override public boolean supportsParameter(MethodParameter parameter) { return parameter.getParameterType().isAssignableFrom(CurrentUser.class); } Override public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception { HttpServletRequest request (HttpServletRequest) webRequest.getNativeRequest(); Long userId (Long) request.getAttribute(currentUserId); return new CurrentUser(userId); } }注册方式Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addArgumentResolvers(ListHandlerMethodArgumentResolver resolvers) { resolvers.add(new CurrentUserArgumentResolver()); } }之后所有Controller方法里只要参数类型是CurrentUserSpring就会在进入方法前自动从Request的attribute里取出信息并构造对象GetMapping(/profile) public ResultProfileVO profile(CurrentUser currentUser) { return userService.getProfile(currentUser.getUserId()); }这套机制和“获取Request对象”的关系在于resolveArgument里拿到的NativeWebRequest本质就是当前HTTP请求你可以在任何业务参数进入方法之前从Request里解析出你真正想给方法的数据。它是这几类方法里最“工程化”的用法适合统一处理“当前登录用户”、“请求幂等号”、“租户ID”这类公共参数。4.4 三个入口的时机对比为了方便理解把Filter、Interceptor、ArgumentResolver三者放到一张表里对比入口执行时机能否拿到Request典型用途FilterDispatcherServlet之前最先执行可以ServletRequest强转跨域、日志、链路ID、签名校验HandlerInterceptorDispatcherServlet之后Controller方法之前可以preHandle已有该参数登录校验、权限判断、公共数据组装HandlerMethodArgumentResolverInterceptor之后进入Controller方法之前可以NativeWebRequest中获取自动注入当前用户、幂等号等公共参数三者叠加使用时顺序是Filter → DispatcherServlet → Interceptor.preHandle → ArgumentResolver.resolveArgument → Controller方法。想在哪一层拿Request取决于你的业务代码需要多靠后执行。5. 最容易翻车的场景异步线程拿不到Request5.1 复现现场Async和线程池里取到null实战里最容易出问题的就是异步场景。很多同事写完上面的RequestContextUtil第二天在Async方法里用它取IP突然就抛了IllegalStateException或NPE。代码长这样Service public class NotifyService { Async public void sendNotify(Long userId, String content) { // 到这里想取当前登录用户却拿到null HttpServletRequest request RequestContextUtil.getRequest(); // 异常 } }原因我在第3.2节说过了RequestContextHolder把Request存在ThreadLocal里而ThreadLocal是线程私有的。主线程Tomcat处理请求的线程经过RequestContextFilter时绑定了Request但你调用Async方法时Spring把任务交给了另一个线程池线程那是一个全新的线程压根没经过请求过滤器自然取不到任何RequestAttributes。不只是Async下面这些场景都会遇到同样的问题使用CompletableFuture.supplyAsync构建异步任务使用线程池ExecutorService执行任务使用EnableScheduling的定时任务里调用业务方法使用消息队列消费者MQ消费时本身就没有Request上下文手动new Thread起的临时线程。5.2 解决方案一进入异步前显式传递最简单的解决办法在进入异步任务之前把需要的Request数据取出来作为参数传给异步方法不要在子线程里依赖ThreadLocal。Async public void sendNotify(Long userId, String content, String clientIp) { // 直接用clientIp不碰RequestContextHolder }调用方String clientIp RequestContextUtil.getClientIp(); notifyService.sendNotify(userId, content, clientIp);如果子线程里确实需要完整的Request对象比如读取header、读取请求体也可以在进入异步前拿到Request实例再传进去HttpServletRequest currentRequest RequestContextUtil.getRequest(); completableFuture.supplyAsync(() - doSomething(currentRequest));但这种做法要谨慎后面会细说。5.3 解决方案二TaskDecorator自动恢复如果项目里大量地方用到线程池且期望子线程能自动继承主线程的RequestAttributes可以自定义一个TaskDecorator在任务提交时把主线程的RequestAttributes带过去任务执行完清理掉。Configuration public class ThreadPoolConfig { Bean(asyncExecutor) public Executor asyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setMaxPoolSize(16); executor.setQueueCapacity(100); executor.setThreadNamePrefix(async-); executor.setTaskDecorator(new RequestContextTaskDecorator()); executor.initialize(); return executor; } } public class RequestContextTaskDecorator implements TaskDecorator { Override public Runnable decorate(Runnable runnable) { RequestAttributes context RequestContextHolder.getRequestAttributes(); return () - { try { RequestContextHolder.setRequestAttributes(context); runnable.run(); } finally { RequestContextHolder.resetRequestAttributes(); } }; } }这样设置之后Async使用的线程池如果指定的是asyncExecutor子线程执行任务前会先把主线程的RequestAttributes设置进去执行完再清掉防止线程复用时数据串台。注意这个方案能解决ThreadLocal的传递问题但对复杂的Request对象是否安全仍然取决于Request内部状态。特别是包含请求输入流、输出流时异步线程里读取可能已经无效。5.4 传递requestId而不是传递完整Request对象最后聊一个我更推荐的做法在异步链路里尽量传“轻量数据”而不是传整个Request对象。Request对象本身绑定了Servlet容器的连接、输入输出流等底层资源生命周期和请求一致。异步线程可能比请求活得久请求处理完连接关闭了你再拿着Request对象去调用它内部的方法大概率会拿到一堆异常。而且把整个Request对象传进线程池还可能在并发执行时造成资源竞争。常见的做法是把需要的字段抽出来比如链路ID、用户ID、IP拼成一个轻量上下文对象再传给异步任务。这也是分布式链路追踪系统在Async场景下常用的思路通过MDC把traceId传递给子线程不在子线程里访问Servlet对象。Async public void sendNotify(AsyncContext context) { // context里只有userId、clientIp、traceId这些普通字段 }这个思路其实比TaskDecorator更稳TaskDecorator帮你继承了上下文但同时继承的还有一堆容易过期的Servlet关联对象显式传参虽然代码看起来朴实但语义清晰、生命周期清晰也不容易出玄学问题。6. 高频追问作用域、自动装配和测试环境6.1 Autowired注入HttpServletRequest为什么能用这是面试中出现率很高的问题。很多人在代码里这么写RestController public class UserController { Autowired private HttpServletRequest request; GetMapping(/ping) public String ping() { return request.getRequestURI(); } }Controller是单例BeanHttpServletRequest却是每个请求一个为什么注入到单例里的request还能用因为你的方法调用最终发生在请求线程内Spring在Web环境里为request作用域提供了代理Bean。你注入的不是某个具体请求对象而是一个代理对象每次调用代理的方法时代理会从当前线程绑定的RequestAttributes里找到真实的Request再执行实际调用。为了对用户隐藏差异Spring容器内部通过作用域代理scoped proxy实现所以编译期、运行期都正常不会报错。这个做法的优点是代码少缺点是隐式依赖。如果你在一个不在请求上下文里调用这个方法的地方定时任务线程访问它同样会拿到null或抛异常。6.2 多次获取Request是同一个对象吗另一个经常被追问的细节是同一个请求里通过Controller参数注入拿到的Request和RequestContextHolder里取到的Request是不是同一个对象答案通常是同一个但不是绝对的。原因在于Filter链上可能出现过Request包装。比如Spring Security会使用FilterSecurityInterceptor、OncePerRequestFilter等包装Request处理完之后你把包装之后的Request放到了Filter链里那么你后面拿到的可能是经过包装的实例。SpringMVC在解析Controller参数时默认拿到的就是当前Filter链传递下来的请求对象。只要中间没有再次包装Controller参数和RequestContextHolder取出来的是同一个实例。不过业务上不用对“是不是同一个对象”太纠结更应该关注“同一个请求里的信息是否一致”。只要处理同一个请求从不同入口拿到的Request数据应当保持一致因为即使实例不同它们最终也共享相同的header、parameter、attribute数据源。如果你在Filter里对请求流做了包装比如用ContentCachingRequestWrapper缓存请求体要特别小心包装类的输入流只能读一次处理完后Controller里再读request.getInputStream()可能读到空流。这也是为什么要用ContentCachingRequestWrapper这种缓存型包装而不是直接包裹。6.3 单元测试里怎么模拟Request写单测时也会遇到拿Request的问题。SpringBoot里推荐用MockHttpServletRequest配合MockMvc模拟完整的请求处理链路SpringBootTest AutoConfigureMockMvc class UserControllerTest { Autowired private MockMvc mockMvc; Test void testGetUserInfo() throws Exception { mockMvc.perform(get(/api/user/info) .param(id, 100) .header(Authorization, Bearer test-token)) .andExpect(status().isOk()); } }对于Service层单测如果你用了RequestContextHolder取Request单测里可以手动设置RequestAttributesTest void testRequestContextUtil() { MockHttpServletRequest request new MockHttpServletRequest(); RequestContextHolder.setRequestAttributes(new ServletRequestAttributes(request)); try { String ip RequestContextUtil.getClientIp(); assertEquals(127.0.0.1, ip); } finally { RequestContextHolder.resetRequestAttributes(); } }不过我更建议在Service层的设计上尽量少依赖RequestContextHolder把要用的数据通过方法参数传入这样单测时完全不需要模拟Web环境业务逻辑更干净。6.4 我现在的写法建议绕了一圈再说回怎么选。我的个人习惯是Controller层能声明参数就声明参数需要RequestMapping拿Request就加一个HttpServletRequest参数只在Controller层使用。Service层如果有公共的请求上下文需求封装一个线程安全的RequestContextUtil内部用RequestContextHolder实现但保证调用点都在请求线程里。异步场景不传Request对象抽一个AsyncContext对象传必要字段。全局公共参数注入用自定义HandlerMethodArgumentResolver把当前用户等对象直接绑进Controller方法参数。登录/权限/链路追踪用HandlerInterceptor和Filter注意不要重复包装、不要多次读取请求体。这些组合下来代码可读性、可测试性都不错面试里把这些场景讲清楚也比单纯背“四种方法”要有说服力得多。
SpringBoot中获取Request对象的几种方法，从Controller到异步线程全解析
1. 从一次“取不了Request”的求助说起1.1 面试官为什么总把“几种方法”挂在嘴边一次组里来了个新人改一个老项目需求不复杂在操作日志里记录当前登录用户的IP。Controller里他轻车熟路地拿了HttpServletRequest但日志记录逻辑写在Service层Service方法签名里压根没有request参数。他跑过来问我“在Service里怎么拿Request对象网上答案一搜好几套有的说参数注入有的说RequestContextHolder有的说直接Autowired到底哪个是对的”这个问题其实也是SpringBoot面试里的常见题问法通常是“SpringBoot有几种获取Request对象的方法”。不少面试者能答出“Controller方法参数注入”和“RequestContextHolder”但再往深了问Filter和Interceptor里能不能拿HandlerMethodArgumentResolver又是干嘛的异步线程里为什么拿不到很多人就卡住了。“几种方法”这四个字面试官真正想考察的并不是你背了几个API而是你对SpringMVC请求处理链路的理解。Request对象从Servlet容器进入DispatcherServlet之后Spring在链路的不同节点都留有入口你的方法就藏在不同的入口里。1.2 Request在SpringMVC里到底经过了哪些入口要理解这个问题先想清楚Servlet层的事情。Servlet规范定义了HttpServletRequest由Servlet容器Tomcat是SpringBoot默认容器创建容器把请求包装成Request对象然后在Filter链里传递最终交给Servlet处理。SpringBoot里的DispatcherServlet本质上就是一个Servlet它接收到的Request对象和你在Filter里看到的是同一个东西可能被包装过一次或多次。到了DispatcherServlet内部SpringMVC又做了一层加工DispatcherServlet根据URL找HandlerMapping定位到具体的方法再把Request对象交给HandlerAdapterHandlerAdapter内部会调用一组HandlerMethodArgumentResolver把Request对象里的header、parameter、body、cookie等内容解析出来绑定到Controller方法的参数上。所以“获取Request对象”在SpringBoot里其实不是一个单一入口而是Spring在请求生命周期的多个环节都暴露了入口Controller方法签名里声明参数由参数解析器注入整个请求处理线程里通过RequestContextHolder拿静态绑定Filter链和HandlerInterceptor的preHandle方法中直接拿到Request自定义HandlerMethodArgumentResolver在进入Controller之前把你想绑定的东西做好容器里使用request作用域的Bean让Spring内部帮你注入代理对象。这五类入口对应了从Servlet层到SpringMVC方法调用的全过程。接下来我按实际使用频率和场景逐个拆开讲。2. 常规写法方法参数注入在Controller里直接拿2.1 最简单的声明式获取最常用的方式没有之一就是在Controller方法里直接声明HttpServletRequest参数。SpringMVC内置的ServletRequestMethodArgumentResolver看到方法参数类型是HttpServletRequest会直接把当前的Request对象塞进去。RestController RequestMapping(/api/user) public class UserController { GetMapping(/info) public ResultUserInfo info(HttpServletRequest request, RequestParam Long id) { String token request.getHeader(Authorization); String ip getClientIp(request); UserInfo user userService.queryById(id); return Result.ok(user); } }这方法写起来最省事也不需要额外引入任何东西。你可以在方法体里读取header、读取请求参数、读取request的attribute还可以通过request.getSession()拿到会话对象。同时也可以配合RequestParam、RequestHeader、PathVariable这些注解拿具体的数据而Request本身作为“兜底”用于处理一些注解不太好表达的场景。2.2 为什么说能拿参数就别在Service里翻Request这里给个建议虽然参数注入是拿Request最直白的方式但在Controller里拿到Request之后不要顺手把整个对象传进Service。原因有三个第一耦合度高。Service层一旦出现HttpServletRequest说明业务逻辑和Web容器绑定了以后如果你想把这个Service复用到定时任务、消息队列消费里它就会成为一个障碍因为那些场景根本没有Request。第二不易测试。Service方法依赖Request对象后单元测试要构造一个完整的MockRequest才能跑成本凭空高出一截。第三参数语义不清晰。Service方法更好的入参是“业务需要的数据”而不是“包含很多数据的容器对象”。比如登录用户ID、客户端IP、链路ID这些你可以在Controller层抽成普通的Java参数传下去。我实际见到很多老项目里Service层到处是request.getParameter(xxx)结果后续加一个定时任务导出报表功能只能再写一套“无Request版本”的逻辑代码越来越难维护。所以参数注入只建议用在Controller层隔离组合交给下一层处理。2.3 配合注解拿参数的常见操作除了直接拿RequestSpringMVC还给了几个更精准的注解很多场景下甚至不需要Request对象GetMapping(/order) public ResultOrder getOrder(RequestHeader(X-User-Id) Long userId, RequestParam(value orderNo, required true) String orderNo, CookieValue(name SESSION, required false) String sessionId) { // 直接使用userId、orderNo、sessionId }RequestHeader拿单个请求头RequestParam拿URL参数或表单参数CookieValue拿CookieRequestBody拿JSON对象。这是主流写法也是SpringBoot里声明式获取参数的标准姿势。只有当你要读取所有Header做遍历、把请求流转成字符串再做业务解析、或者从attribute里取拦截器放进去的临时标记时才真正需要拿到HttpServletRequest对象本身。写在这里是想提醒大家方法参数注入是最常用的“获取Request对象的方法”但在大多数Controller方法里我们并不真的需要Request需要的只是它里面的业务数据。把数据声明出来比传递整个Request更优雅。3. 脱离ControllerRequestContextHolder的搬运法3.1 Service层和工具类里应该怎么写回到一开始那个新人的问题Service方法里没有HttpServletRequest参数但就是要拿客户端IP怎么办Spring提供了一个静态工具类RequestContextHolder它可以在当前请求处理线程内取到绑定的ServletRequestAttributes再从里面拿Request。标准写法如下public class RequestContextUtil { public static HttpServletRequest getRequest() { RequestAttributes attributes RequestContextHolder.getRequestAttributes(); if (attributes instanceof ServletRequestAttributes) { return ((ServletRequestAttributes) attributes).getRequest(); } throw new IllegalStateException(当前线程没有绑定Request请确认是否在HTTP请求线程中调用); } public static String getClientIp() { HttpServletRequest request getRequest(); String ip request.getHeader(X-Forwarded-For); if (ip null || ip.isEmpty()) { ip request.getRemoteAddr(); } return ip; } }用的时候就是在Service里直接调Service public class AuditLogService { public void record(String operation) { HttpServletRequest request RequestContextUtil.getRequest(); String ip RequestContextUtil.getClientIp(); auditLogMapper.insert(new AuditLog(operation, ip)); } }这样Service方法的签名保持干净业务代码又确实拿到了Request信息是很多项目在做的折中方案。3.2 ThreadLocal原理为什么同一线程内都能拿到RequestContextHolder的实现核心是一个ThreadLocalpublic abstract class RequestContextHolder { private static final ThreadLocalRequestAttributes requestAttributesHolder new NamedThreadLocal(Request attributes); }DispatcherServlet在处理请求时通过RequestContextFilter或者RequestContextListener把当前的ServletRequestAttributes放进去请求处理结束再清理。于是只要是同一个线程内的代码不管是在Controller层、Service层还是某个工具类里都能通过这个静态变量取到当前请求的上下文。这正是它和“方法参数注入”最大的区别方法参数注入是Spring在调用方法时把Request塞给指定的参数是“显式传递”RequestContextHolder是Spring把Request“挂”在了当前线程上你需要时自己取是“隐式访问”。有一点要注意RequestContextHolder.getRequestAttributes()返回的是RequestAttributes接口不是HttpServletRequest。实际类型往往是ServletRequestAttributes必须做一次类型判断和强转。有的从RequestContextHolder拿request不看类型就强转遇到自定义的RequestAttributes实现时会抛ClassCastException。上面代码里用了instanceof判断就是防这个。3.3 使用RequestContextHolder的几个强制注意点RequestContextHolder不是万能的使用时有几个必须记住的注意事项只能在处理HTTP请求的线程里调用。Async异步方法、线程池任务、定时任务、MQ消费者中getRequestAttributes()返回null。这几乎是新手踩得最多的坑后面第5节详细说。不要在请求处理完之后保存Request对象。请求结束线程绑定会被清理Request对象本身也会被容器回收这时候再访问里面的数据是不可靠的。如果方法可能在非Web场景被复用建议先判断attributes null。比如同一个Service方法既被Controller调用又被定时任务调用直接调用getRequest()就会抛异常做空判断能避免线上告警。慎用request.getSession()。在高并发场景下顺手调getSession()会创建会话并可能带来会话锁竞争不是所有请求都需要会话。跨线程传递时要格外小心下文会专门讲。4. 请求链路里的其他入口Filter、Interceptor、自定义参数解析器4.1 Filter在进入SpringMVC之前就拿到RequestFilter是Servlet规范定义的组件执行时机比DispatcherServlet更早。SpringBoot里注册一个自定义Filter很简单Component public class TraceFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest httpRequest (HttpServletRequest) request; String traceId httpRequest.getHeader(X-Trace-Id); if (!StringUtils.hasText(traceId)) { traceId UUID.randomUUID().toString().replace(-, ); } httpRequest.setAttribute(traceId, traceId); chain.doFilter(request, response); } }这里的request参数类型是ServletRequest在实际HTTP请求场景中就是HttpServletRequest所以强转是安全的。Filter适合做链路追踪、跨域处理、请求日志、接口签名校验这类需要在SpringMVC介入之前完成的事情。这里要提醒一个细节如果你使用了Spring的OncePerRequestFilterSpringBoot常见的写法它保证了同一个请求只过一遍Filter避免转发等情况下重复执行。做登录鉴权、请求日志这种操作能用OncePerRequestFilter就尽量用它。Component public class JwtAuthFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String token request.getHeader(Authorization); // 校验token... filterChain.doFilter(request, response); } }4.2 Interceptor在每个请求进入Handler前处理HandlerInterceptor是SpringMVC提供的切面接口它位于DispatcherServlet之后、Controller方法之前比Filter更接近业务层。它的preHandle方法自带HttpServletRequest参数public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } String token request.getHeader(Authorization); if (!StringUtils.hasText(token)) { response.setStatus(401); return false; } Long userId jwtService.parseUserId(token); request.setAttribute(currentUserId, userId); return true; } }注册Interceptor通常配合WebMvcConfigurerConfiguration public class WebMvcConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/login, /api/register); } }Interceptor中最重要的一个特征preHandle返回false可以终止请求而Filter做不到这么细粒度的业务阻断当然Filter里也能直接返回响应但Interceptor对HandlerMethod有感知能判断是不是真正的处理器方法。在Interceptor里你既可以直接拿Request也能通过request.setAttribute把处理结果存给后续的Controller使用Controller里再用HttpServletRequest.getAttribute取出来。4.3 自定义ArgumentResolver把“公共参数”变成方法参数如果你觉得每个方法手写“从Request取当前登录用户”这段代码太重复可以把这一步交给HandlerMethodArgumentResolver。它才是SpringMVC参数绑定的底层机制。public class CurrentUserArgumentResolver implements HandlerMethodArgumentResolver { Override public boolean supportsParameter(MethodParameter parameter) { return parameter.getParameterType().isAssignableFrom(CurrentUser.class); } Override public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception { HttpServletRequest request (HttpServletRequest) webRequest.getNativeRequest(); Long userId (Long) request.getAttribute(currentUserId); return new CurrentUser(userId); } }注册方式Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addArgumentResolvers(ListHandlerMethodArgumentResolver resolvers) { resolvers.add(new CurrentUserArgumentResolver()); } }之后所有Controller方法里只要参数类型是CurrentUserSpring就会在进入方法前自动从Request的attribute里取出信息并构造对象GetMapping(/profile) public ResultProfileVO profile(CurrentUser currentUser) { return userService.getProfile(currentUser.getUserId()); }这套机制和“获取Request对象”的关系在于resolveArgument里拿到的NativeWebRequest本质就是当前HTTP请求你可以在任何业务参数进入方法之前从Request里解析出你真正想给方法的数据。它是这几类方法里最“工程化”的用法适合统一处理“当前登录用户”、“请求幂等号”、“租户ID”这类公共参数。4.4 三个入口的时机对比为了方便理解把Filter、Interceptor、ArgumentResolver三者放到一张表里对比入口执行时机能否拿到Request典型用途FilterDispatcherServlet之前最先执行可以ServletRequest强转跨域、日志、链路ID、签名校验HandlerInterceptorDispatcherServlet之后Controller方法之前可以preHandle已有该参数登录校验、权限判断、公共数据组装HandlerMethodArgumentResolverInterceptor之后进入Controller方法之前可以NativeWebRequest中获取自动注入当前用户、幂等号等公共参数三者叠加使用时顺序是Filter → DispatcherServlet → Interceptor.preHandle → ArgumentResolver.resolveArgument → Controller方法。想在哪一层拿Request取决于你的业务代码需要多靠后执行。5. 最容易翻车的场景异步线程拿不到Request5.1 复现现场Async和线程池里取到null实战里最容易出问题的就是异步场景。很多同事写完上面的RequestContextUtil第二天在Async方法里用它取IP突然就抛了IllegalStateException或NPE。代码长这样Service public class NotifyService { Async public void sendNotify(Long userId, String content) { // 到这里想取当前登录用户却拿到null HttpServletRequest request RequestContextUtil.getRequest(); // 异常 } }原因我在第3.2节说过了RequestContextHolder把Request存在ThreadLocal里而ThreadLocal是线程私有的。主线程Tomcat处理请求的线程经过RequestContextFilter时绑定了Request但你调用Async方法时Spring把任务交给了另一个线程池线程那是一个全新的线程压根没经过请求过滤器自然取不到任何RequestAttributes。不只是Async下面这些场景都会遇到同样的问题使用CompletableFuture.supplyAsync构建异步任务使用线程池ExecutorService执行任务使用EnableScheduling的定时任务里调用业务方法使用消息队列消费者MQ消费时本身就没有Request上下文手动new Thread起的临时线程。5.2 解决方案一进入异步前显式传递最简单的解决办法在进入异步任务之前把需要的Request数据取出来作为参数传给异步方法不要在子线程里依赖ThreadLocal。Async public void sendNotify(Long userId, String content, String clientIp) { // 直接用clientIp不碰RequestContextHolder }调用方String clientIp RequestContextUtil.getClientIp(); notifyService.sendNotify(userId, content, clientIp);如果子线程里确实需要完整的Request对象比如读取header、读取请求体也可以在进入异步前拿到Request实例再传进去HttpServletRequest currentRequest RequestContextUtil.getRequest(); completableFuture.supplyAsync(() - doSomething(currentRequest));但这种做法要谨慎后面会细说。5.3 解决方案二TaskDecorator自动恢复如果项目里大量地方用到线程池且期望子线程能自动继承主线程的RequestAttributes可以自定义一个TaskDecorator在任务提交时把主线程的RequestAttributes带过去任务执行完清理掉。Configuration public class ThreadPoolConfig { Bean(asyncExecutor) public Executor asyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setMaxPoolSize(16); executor.setQueueCapacity(100); executor.setThreadNamePrefix(async-); executor.setTaskDecorator(new RequestContextTaskDecorator()); executor.initialize(); return executor; } } public class RequestContextTaskDecorator implements TaskDecorator { Override public Runnable decorate(Runnable runnable) { RequestAttributes context RequestContextHolder.getRequestAttributes(); return () - { try { RequestContextHolder.setRequestAttributes(context); runnable.run(); } finally { RequestContextHolder.resetRequestAttributes(); } }; } }这样设置之后Async使用的线程池如果指定的是asyncExecutor子线程执行任务前会先把主线程的RequestAttributes设置进去执行完再清掉防止线程复用时数据串台。注意这个方案能解决ThreadLocal的传递问题但对复杂的Request对象是否安全仍然取决于Request内部状态。特别是包含请求输入流、输出流时异步线程里读取可能已经无效。5.4 传递requestId而不是传递完整Request对象最后聊一个我更推荐的做法在异步链路里尽量传“轻量数据”而不是传整个Request对象。Request对象本身绑定了Servlet容器的连接、输入输出流等底层资源生命周期和请求一致。异步线程可能比请求活得久请求处理完连接关闭了你再拿着Request对象去调用它内部的方法大概率会拿到一堆异常。而且把整个Request对象传进线程池还可能在并发执行时造成资源竞争。常见的做法是把需要的字段抽出来比如链路ID、用户ID、IP拼成一个轻量上下文对象再传给异步任务。这也是分布式链路追踪系统在Async场景下常用的思路通过MDC把traceId传递给子线程不在子线程里访问Servlet对象。Async public void sendNotify(AsyncContext context) { // context里只有userId、clientIp、traceId这些普通字段 }这个思路其实比TaskDecorator更稳TaskDecorator帮你继承了上下文但同时继承的还有一堆容易过期的Servlet关联对象显式传参虽然代码看起来朴实但语义清晰、生命周期清晰也不容易出玄学问题。6. 高频追问作用域、自动装配和测试环境6.1 Autowired注入HttpServletRequest为什么能用这是面试中出现率很高的问题。很多人在代码里这么写RestController public class UserController { Autowired private HttpServletRequest request; GetMapping(/ping) public String ping() { return request.getRequestURI(); } }Controller是单例BeanHttpServletRequest却是每个请求一个为什么注入到单例里的request还能用因为你的方法调用最终发生在请求线程内Spring在Web环境里为request作用域提供了代理Bean。你注入的不是某个具体请求对象而是一个代理对象每次调用代理的方法时代理会从当前线程绑定的RequestAttributes里找到真实的Request再执行实际调用。为了对用户隐藏差异Spring容器内部通过作用域代理scoped proxy实现所以编译期、运行期都正常不会报错。这个做法的优点是代码少缺点是隐式依赖。如果你在一个不在请求上下文里调用这个方法的地方定时任务线程访问它同样会拿到null或抛异常。6.2 多次获取Request是同一个对象吗另一个经常被追问的细节是同一个请求里通过Controller参数注入拿到的Request和RequestContextHolder里取到的Request是不是同一个对象答案通常是同一个但不是绝对的。原因在于Filter链上可能出现过Request包装。比如Spring Security会使用FilterSecurityInterceptor、OncePerRequestFilter等包装Request处理完之后你把包装之后的Request放到了Filter链里那么你后面拿到的可能是经过包装的实例。SpringMVC在解析Controller参数时默认拿到的就是当前Filter链传递下来的请求对象。只要中间没有再次包装Controller参数和RequestContextHolder取出来的是同一个实例。不过业务上不用对“是不是同一个对象”太纠结更应该关注“同一个请求里的信息是否一致”。只要处理同一个请求从不同入口拿到的Request数据应当保持一致因为即使实例不同它们最终也共享相同的header、parameter、attribute数据源。如果你在Filter里对请求流做了包装比如用ContentCachingRequestWrapper缓存请求体要特别小心包装类的输入流只能读一次处理完后Controller里再读request.getInputStream()可能读到空流。这也是为什么要用ContentCachingRequestWrapper这种缓存型包装而不是直接包裹。6.3 单元测试里怎么模拟Request写单测时也会遇到拿Request的问题。SpringBoot里推荐用MockHttpServletRequest配合MockMvc模拟完整的请求处理链路SpringBootTest AutoConfigureMockMvc class UserControllerTest { Autowired private MockMvc mockMvc; Test void testGetUserInfo() throws Exception { mockMvc.perform(get(/api/user/info) .param(id, 100) .header(Authorization, Bearer test-token)) .andExpect(status().isOk()); } }对于Service层单测如果你用了RequestContextHolder取Request单测里可以手动设置RequestAttributesTest void testRequestContextUtil() { MockHttpServletRequest request new MockHttpServletRequest(); RequestContextHolder.setRequestAttributes(new ServletRequestAttributes(request)); try { String ip RequestContextUtil.getClientIp(); assertEquals(127.0.0.1, ip); } finally { RequestContextHolder.resetRequestAttributes(); } }不过我更建议在Service层的设计上尽量少依赖RequestContextHolder把要用的数据通过方法参数传入这样单测时完全不需要模拟Web环境业务逻辑更干净。6.4 我现在的写法建议绕了一圈再说回怎么选。我的个人习惯是Controller层能声明参数就声明参数需要RequestMapping拿Request就加一个HttpServletRequest参数只在Controller层使用。Service层如果有公共的请求上下文需求封装一个线程安全的RequestContextUtil内部用RequestContextHolder实现但保证调用点都在请求线程里。异步场景不传Request对象抽一个AsyncContext对象传必要字段。全局公共参数注入用自定义HandlerMethodArgumentResolver把当前用户等对象直接绑进Controller方法参数。登录/权限/链路追踪用HandlerInterceptor和Filter注意不要重复包装、不要多次读取请求体。这些组合下来代码可读性、可测试性都不错面试里把这些场景讲清楚也比单纯背“四种方法”要有说服力得多。
