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

興和網站制作公司哪家好,找創(chuàng)新互聯(lián)公司!從網頁設計、網站建設、微信開發(fā)、APP開發(fā)、響應式網站設計等網站項目制作,到程序開發(fā),運營維護。創(chuàng)新互聯(lián)公司從2013年開始到現(xiàn)在10年的時間,我們擁有了豐富的建站經驗和運維經驗,來保證我們的工作的順利進行。專注于網站建設就選創(chuàng)新互聯(lián)公司。
一開始以為是前端同學請求的接口有誤,但是測試又說只是偶然性的404,幾率也不高,于是打開日志找到對應的接口,一眼看到了接口上定義的@PathVariable,再一看參數(shù),基本就確定是開發(fā)同學為了偷懶又誤用@PathVariable導致的了。
先說結論吧:@PathVariable可以使請求參數(shù)動態(tài)的綁定到URL上,但是如果請求參數(shù)中包含特殊字符,比如 /,就可能導致Spring匹配到一個錯誤的URL,或者匹配不到合適的URL。
復現(xiàn)
下面,我用一個簡單的偽代碼復現(xiàn)一下這個bug,與大家分析一下這個bug發(fā)生的原因,以及如何解決,最后順便再通過源碼加深一下印象。
如下,我們定義一個接口,并且通過@PathVariable將入參動態(tài)的綁定到URL上。
@RestController
@RequestMapping(value = "/demo")
public class DemoController {
@GetMapping(value = "/getVal/{val}")
public ResponseEntity
然后我們測試一下這個接口:
正常情況下,我們輸入一個普通無特殊符號的參數(shù),控制臺也成功打印了出來。
但是業(yè)務參數(shù)往往是不可控的,比如當參數(shù)變成“ hello/world”時,代碼就不能正常執(zhí)行了。
大家可以從圖中看到,Spring將原本預期的URL:/demo/getVal/{val},解析成了/demo/getVal/hello/world。
而之所以測試同學最近才發(fā)現(xiàn)這個接口有問題,也正是因為上線之初并沒有遇到帶有/的參數(shù),所以接口看起來是正常的,直到最近在生產環(huán)境遇到了一個帶/的參數(shù)。
正確的做法是:將URL定義為/demo/getVal,然后將參數(shù)通過表單或者query的方式傳遞。
?解決的辦法很簡單,相信有點經驗的同學都能很快將這個問題修復。
但是知其然,更要知其所以然,順著這個問題,我們探究一下Spring究竟是如何解析URL的。?
首先,我們找到Spring webmvc的包,在
org.springframework.web.servlet.handler包下找到AbstractHandlerMethodMapping類,這個類就是會將我們定義的mapping和URL綁定起來。
這個類中的lookupHandlerMethod方法,會查找當前請求的最佳匹配處理程序方法,并且如果找到多個匹配項,就選擇最佳匹配項。
分析這個方法,我們可以得到這樣3個匹配步驟:
1、根據Path精準匹配
2、如果精準匹配沒有成功,就開始模糊匹配
3、如果模糊匹配還匹配不上,就返回null
至此,一個URL解析的過程就完畢了。單看源碼可以發(fā)現(xiàn),邏輯其實并不復雜,就是一個按照規(guī)則不斷匹配的過程。
最后
總得來說,@PathVariable可以讓我們開發(fā)接口的時候省去一些功夫,但是需要注意到,如果綁定的參數(shù)帶有特殊字符,就有可能導致非預期的bug。
一般來說,@PathVariable比較適合綁定整型的參數(shù),如果是字符串類的參數(shù),建議大家還是通過表單或json的方式傳參。
新聞標題:因為濫用@PathVariable導致的Bug,開發(fā)同學又背鍋了
網站路徑:http://www.dlmjj.cn/article/dpsiepi.html


咨詢
建站咨詢
