序言
前段时间试验老师意见反馈，上周五上架的两个机能会随机性的报404，Lendelin那个机能在试验环境已经试验透过，也新浪网上运转了好两天，怎么会忽然收起呢。
一已经开始误以为是后端老师允诺的USB不确，但试验又说而已随机性的404，机率也不高，于是关上笔记找出相关联的USB，一看看见了USB上表述的@PathVariable，再细看模块，基本上就确认是合作开发老师为的是贪心又误为@PathVariable引致的了。
先说推论吧：@PathVariable可以使允诺模块静态的存取到URL上，但假如允诺模块中包涵转义，比如说 /,就可能将引致Spring相匹配到两个严重错误的URL，或是相匹配不出最合适的URL。
Cadours
上面，布季谢两个单纯的伪标识符Cadours呵呵那个bug，与我们预测呵呵那个bug出现的其原因，和怎样化解，最终别忘了再透过源代码增进呵呵第一印象。
如下表所示，他们表述两个USB，因此透过@PathVariable将入参静态的存取到URL上。
@RestController@RequestMapping(value = “/demo”)public class DemoController {@GetMapping(value = “/getVal/{val}”)public ResponseEntity getVal(@PathVariable String val){System.out.println(“模块:” + val);return ResponseEntity.ok(val);
接着他们试验呵呵那个USB：
恒定情况下，他们输出两个一般无标点符号的模块，控制面板也获得成功列印了出。
但销售业务模块常常是不受控的，比如说当模块变为“ hello/world”时，标识符就无法恒定继续执行了。
我们可以从图中看见，Spring将原本预期的URL：/demo/getVal/{val}，解析成了/demo/getVal/hello/world。
而之所以试验老师最近才发现那个USB有问题，也正是即使上架之初并没有遇到带有/的模块，所以USB看起来是恒定的，直到前段时间在生产环境遇到了两个带/的模块。
正确的做法是：将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可以让他们合作开发USB的时候省去一些功夫，但需要注意到，假如存取的模块带有转义，就有可能将引致非预期的bug。
一般来说，@PathVariable比较适合存取整型的模块，假如是字符串类的模块，建议我们还是透过表单或json的方式传参。
#头条创作挑战赛##2022生机大会#
我是@程序员拾山，欢迎关注我，期待与我们一起学习成长，也感谢您的点赞和关注。
