一次请求的旅程：从 URL 到你的 Controller 方法

写 Spring 的时候。我经常有一种错觉：好像只要在 Controller 里放一个方法，浏览器敲个地址，参数就会自己进来返回值就会自己变成 JSON 还给使用者。怎么说呢，好像 Tomcat 是某个神秘组织，在幕后默默替我打理一切。

直到有一天我认真问自己：

• @GetMapping 里的 {id} 是怎么被提取出来的？
• 方法里那个 Long id 又是谁塞进来的？
• 如果想拦一下请求，到底该往哪一层加代码？

目录

Tomcat 根本不认识你的 Controller

这是整件事的起点，也是最容易搞反的一点。

Tomcat 是一个Servlet 容器。它只负责四件事：

1. 监听端口、接收字节流；不过，二、解析成 HTTP 请求；其实，三、把请求转交给“某个 Servlet”；四、将响应返回，

你可能以为 Tomcat 能直接调用你写的业务代码，但其实它只认得 Servlet 接口：

public interface Servlet {
void init;void service;void destroy;}
}

Your UserController is never in Tomcat’s sight.

The only servlet registered with Tomcat is single one called . That is how Tomcat hands every request off to Spring.

If you imagine Tomcat as a hospital's reception desk that knows only about “direct patients to right department”,it doesn’t know any doctors. The dispatcher servlet plays that role。routing you based on your appointment to correct department .

进入 Spring 的世界：doDispatch 干了什么

The dispatcher servlet extends HttpServlet»,so for Tomcat it’s just anor ordinary servlet.

protected void doDispatch(HttpServletRequest request,HttpServletResponse response) {
// . Find a handler for this request
HandlerExecutionChain mappedHandler = getHandler;// . Get an adapter that can execute this handler
HandlerAdapter ha = getHandlerAdapter);// . Execute interceptor chain if present
mappedHandler.applyPreHandle;// . Call your controller method
ModelAndView mv = ha.handle(request。response,mappedHandler.getHandler);// . Process return value
processDispatchResult(processedRequest。response,mappedHandler,mv);}
}

This heart of Spring MVC does little—just five steps—but hides its design choice:

• The dispatcher doesn't care what your handler looks like;it could be a @RequestMapping method,an old-style Controller interface or anything else.
• You just tell it how to execute via a HandlerAdapter.
• This keeps DispatcherServlet decoupled from concrete handler implementations.
• The pattern is Adapter Pattern in action.

第一步先：URL 是怎么找到你的方法的

The core of this step is handled by RequestMappingHandlerMapping.

Your application starts up by scanning all classes annotated with @Controller or @RestController. For each method annotated with @RequestMapping / @GetMapping / @PostMapping etc.。Spring builds an internal lookup table:

GET /users/{id} → UserController.getUser
POST /users → UserController.createUser
...
}

This mapping table is built once at startup and consulted for every incoming request.

The result of that lookup isn’t simply a method reference—it’s an object called ,which bundles information about:

• The owning bean instance;
. • The Method object;. • Parameter types and annotations.

接下来：@PathVariable 里的参数是谁塞进去的

Soon after adapter decides which controller method will run,it needs to supply arguments.

If you wrote:

'getUser'。spring can’t just guess an ID—it must fetch it from somewhere else.
That “somewhere” is handled by a group of objects called HandlerMethodArgumentResolver.
Each resolver declares two methods:
supportsParameter -> can I handle this?resolveArgument -> what value should I provide?



Pain Point – What if my path variable contains special characters?话说回来，

You’ll quickly realize different annotations correspond to distinct resolver implementations:


@RequestParam → query string like?page=，;

@RequestHeader → HTTP headers;

@PathVariable → part of URL path;

@CookieValue → Cookie values;

@RequestBody → request body .



Pain Point – Why does MyBatis map parameters differently than Spring MVC?

The mapping logic in PathVariableMethodArgumentResolver works like this:

· It sees that re’s an annotation on parameter;说起来，· From matched URL template it pulls out “{id}” – e.g.,if you hit GET /users/123。it extracts “123”.
· It n uses a type converter to turn that string into Long.
· Now reflection calls getUser.




Pain Point – How can I add custom argument resolution logic?





Pain Point – Can I see which resolver handled my argument?不过，




然后：@RequestBody 是怎么把 JSON 变成对象的 

@RequestBody是参数解析中最特殊的一种。因为它涉及到格式转换，

请求体原始形态是一段JSON字符串：

{"name":"张三","age":27}


而你的方法参数是一个 User 对象。字符串到对象，中间必须有一个“翻译”过程。这个翻译官叫 HttpMessageConverter——HTTP 消息转换器。

处理 @RequestBody 参数的解析器内部会调用 HttpMessageConverter.read。
话说回来，它会看请求头里的 Content‑Type，如果是 application/json，就从注册表里找到 MappingJackson2HttpMessageConverter。接下来委托给 Jackson 的 ObjectMapper 去反序列化，把 JSON 变成 User 对象。

这也顺便解释了一个困扰过很多人的现象：为什么引入 spring‑boot‑starter‑web 后Jackson 就自动可用了。因为 @RequestBody / @ResponseBody 要用到它，Spring Boot 的自动配置就把 MappingJackson2HttpMessageConverter 默认注册好了。


Pain Point ：当我们使用自定义序列化/反序列化逻辑时如何让 Spring 自动识别？答案是实现并注册自己的 HttpMessageConverter，并在配置类里添加到 converters 列表中即可。

第四步：返回值又是怎么变成 JSON 还回去的 

方法返回一个 User 对象，但响应只能承载字节。这个反向翻译还是 HttpMessageConverter 干的——只但是这次调用的是 write 方向。

方法执行完，返回值交给 HandlerMethodReturnValueHandler 来处理。如果方法上标了 @ResponseBody，就会走 RequestResponseBodyMethodProcessor。它调用转换器 write，把 User 对象序列化为 JSON 字符串，写进 HttpServletResponse 响应体里。说起来，

所以 HttpMessageConverter 就是双向翻译官：read 把请求里的 JSON 转成 Java 对象；write 把 Java 对象变成响应里的 JSON。你平时感觉不到它，因为它一直在你根本看不见的地方默默工作。

把整条链串起来 

下面用一句话整个流程： 





NEXT STEP : 浏览器发 HTTP 请求 → Tomcat NIO 接收字节流 → 把报文封装为 HttpServletRequest → 根据 URL 匹配 DispatcherServlet → 调用 service → doDispatch → RequestMappingHandlerMapping 查表得到 UserController.getUser → RequestMappingHandlerAdapter 准备执行 → ArgumentResolver 从 URL 提取 {id} 转为 Long → 调用 getUser → 返回值交给 ReturnValueHandlers 用 MappingJackson…写入响应体作为 Json →











Spring Boot 到底干了什么？

许多人以为 IDE 把 Tomcat 封装好了其实不是这样。Spring Boot 的 main 方法里一系列自动配置类在背后工作。其中 ServletWebServerFactoryAutoConfiguration 会检测类方法下 tomcat-embed-core。接下来创建内嵌 Tomcat 实例——对，你跑 main 时程序已经悄悄启动了完整 Tomcat。随后 DispatcherServletAutoConfiguration 创建 DispatcherServlet 并注册到根方法 / 上，最终 tomcat.start 开始监听端口。说起来，

=IDEA 做的一切仅仅是帮你执行 main。并管理 tomcat-embed-core 依赖。本质上，“Tomcat 被封装”的说法其实指的是 Spring Boot 用几行代码将 Tomcat 当作库内嵌启动。而不是通过外部容器部署运行。




{id} 是由 HandlerMapping 的 URL 模板匹配结果提供，由 PathVariableMethodArgumentResolver 从中抠出来；Long id 则靠类型转换器完成字符串→Long 的转化；如果想拦截请求，可以使用 Servlet Filter 或者更灵活地放在 doDispatch 第一步先中的 HandlerInterceptor 钩子；框架显得像魔法，只因为层与层之间被隐藏掉了。但每一层都极其简单——Tomcat 专门解析报文和调 Servlet；DispatcherServlet 专门查表、找适配器、反射调用；老实说，参数解析器专门从请求里取数据；转换器专门做字符串与对象之间相互翻译。七层叠加，即形成我们日常看到的 “写个方法就能跑”。一切始于 main 中那句不起眼但关键性的 SpringApplication.run.
**痛点解决**：


想看谁处理哪个参数？开启 DEBUG 日志查看 org.springframework.web.method.annotation.*；

想自定义方法变量格式？实现并注册自定义 ArgumentResolver；

想自定义序列化/反序列化？实现并注册自己的 HttpMessageConverter。


 — 一旦你了解这七层机制。你就能精准定位问题，也能自由
各层，实现更细粒度、更高性能、更安全的网站应用。