前言

最近测试同学反馈，上周上线的一个功能会偶然性的报404，按理说这个功能在测试环境已经测试通过，也在线上运行了好几天，怎么会突然报错呢。

一开始以为是前端同学请求的接口有误，但是测试又说只是偶然性的404，几率也不高，于是打开日志找到对应的接口，一眼看到了接口上定义的@PathVariable，再一看参数，基本就确定是开发同学为了偷懒又误用@PathVariable导致的了。

先说结论吧：@PathVariable可以使请求参数动态的绑定到URL上，但是如果请求参数中包含特殊字符，比如 /,就可能导致Spring匹配到一个错误的URL，或者匹配不到合适的URL。

复现

下面，我用一个简单的伪代码复现一下这个bug，与大家分析一下这个bug发生的原因，以及如何解决，最后顺便再通过源码加深一下印象。

如下，我们定义一个接口，并且通过@PathVariable将入参动态的绑定到URL上。

@RestController
@RequestMapping(value = "/demo")
public class DemoController {
    @GetMapping(value = "/getVal/{val}")
    public ResponseEntity<Object> getVal(@PathVariable String val){
        System.out.println("参数:" + val);
        return ResponseEntity.ok(val);
    }    
}
1.
2.
3.
4.
5.
6.
7.
8.
9.

然后我们测试一下这个接口：

正常情况下，我们输入一个普通无特殊符号的参数，控制台也成功打印了出来。

但是业务参数往往是不可控的，比如当参数变成“ hello/world”时，代码就不能正常执行了。

大家可以从图中看到，Spring将原本预期的URL：/demo/getVal/{val}，解析成了/demo/getVal/hello/world。

而之所以测试同学最近才发现这个接口有问题，也正是因为上线之初并没有遇到带有/的参数，所以接口看起来是正常的，直到最近在生产环境遇到了一个带/的参数。

正确的做法是：将URL定义为/demo/getVal，然后将参数通过表单或者query的方式传递。

​解决的办法很简单，相信有点经验的同学都能很快将这个问题修复。

但是知其然，更要知其所以然，顺着这个问题，我们探究一下Spring究竟是如何解析URL的。​

首先，我们找到Spring webmvc的包，在
org.springframework.web.servlet.handler包下找到AbstractHandlerMethodMapping类，这个类就是会将我们定义的mapping和URL绑定起来。

这个类中的lookupHandlerMethod方法，会查找当前请求的最佳匹配处理程序方法，并且如果找到多个匹配项，就选择最佳匹配项。

分析这个方法，我们可以得到这样3个匹配步骤：

1、根据Path精准匹配

2、如果精准匹配没有成功，就开始模糊匹配

3、如果模糊匹配还匹配不上，就返回null

至此，一个URL解析的过程就完毕了。单看源码可以发现，逻辑其实并不复杂，就是一个按照规则不断匹配的过程。

最后

总得来说，@PathVariable可以让我们开发接口的时候省去一些功夫，但是需要注意到，如果绑定的参数带有特殊字符，就有可能导致非预期的bug。

一般来说，@PathVariable比较适合绑定整型的参数，如果是字符串类的参数，建议大家还是通过表单或json的方式传参。