前言

最近測試同學反饋，上周上線的一個功能會偶然性的報404，按理說這個功能在測試環(huán)境已經測試通過，也在線上運行了好幾天，怎么會突然報錯呢。

一開始以為是前端同學請求的接口有誤，但是測試又說只是偶然性的404，幾率也不高，于是打開日志找到對應的接口，一眼看到了接口上定義的@PathVariable，再一看參數，基本就確定是開發(fā)同學為了偷懶又誤用@PathVariable導致的了。

先說結論吧：@PathVariable可以使請求參數動態(tài)的綁定到URL上，但是如果請求參數中包含特殊字符，比如 /,就可能導致Spring匹配到一個錯誤的URL，或者匹配不到合適的URL。

復現

下面，我用一個簡單的偽代碼復現一下這個bug，與大家分析一下這個bug發(fā)生的原因，以及如何解決，最后順便再通過源碼加深一下印象。

如下，我們定義一個接口，并且通過@PathVariable將入參動態(tài)的綁定到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);
    }
}

然后我們測試一下這個接口：

正常情況下，我們輸入一個普通無特殊符號的參數，控制臺也成功打印了出來。

但是業(yè)務參數往往是不可控的，比如當參數變成“ hello/world”時，代碼就不能正常執(zhí)行了。

大家可以從圖中看到，Spring將原本預期的URL：/demo/getVal/{val}，解析成了/demo/getVal/hello/world。

而之所以測試同學最近才發(fā)現這個接口有問題，也正是因為上線之初并沒有遇到帶有/的參數，所以接口看起來是正常的，直到最近在生產環(huán)境遇到了一個帶/的參數。

正確的做法是：將URL定義為/demo/getVal，然后將參數通過表單或者query的方式傳遞。

解決的辦法很簡單，相信有點經驗的同學都能很快將這個問題修復。

但是知其然，更要知其所以然，順著這個問題，我們探究一下Spring究竟是如何解析URL的。

首先，我們找到Spring webmvc的包，在org.springframework.web.servlet.handler包下找到AbstractHandlerMethodMapping類，這個類就是會將我們定義的mapping和URL綁定起來。

這個類中的lookupHandlerMethod方法，會查找當前請求的最佳匹配處理程序方法，并且如果找到多個匹配項，就選擇最佳匹配項。

分析這個方法，我們可以得到這樣3個匹配步驟

3個匹配步驟

1，根據Path精準匹配

2，如果精準匹配沒有成功，就開始模糊匹配

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

至此，一個URL解析的過程就完畢了。單看源碼可以發(fā)現，邏輯其實并不復雜，就是一個按照規(guī)則不斷匹配的過程。

最后

總得來說，@PathVariable可以讓我們開發(fā)接口的時候省去一些功夫，但是需要注意到，如果綁定的參數帶有特殊字符，就有可能導致非預期的bug。

一般來說，@PathVariable比較適合綁定整型的參數，如果是字符串類的參數，建議大家還是通過表單或json的方式傳參。

以上就是濫用@PathVariable導致bug原因分析解決的詳細內容，更多關于@PathVariable導致bug的資料請關注腳本之家其它相關文章！

最新評論