因?yàn)闉E用@PathVariable導(dǎo)致的Bug,開(kāi)發(fā)同學(xué)又背鍋了
前言
最近測(cè)試同學(xué)反饋,上周上線(xiàn)的一個(gè)功能會(huì)偶然性的報(bào)404,按理說(shuō)這個(gè)功能在測(cè)試環(huán)境已經(jīng)測(cè)試通過(guò),也在線(xiàn)上運(yùn)行了好幾天,怎么會(huì)突然報(bào)錯(cuò)呢。
一開(kāi)始以為是前端同學(xué)請(qǐng)求的接口有誤,但是測(cè)試又說(shuō)只是偶然性的404,幾率也不高,于是打開(kāi)日志找到對(duì)應(yīng)的接口,一眼看到了接口上定義的@PathVariable,再一看參數(shù),基本就確定是開(kāi)發(fā)同學(xué)為了偷懶又誤用@PathVariable導(dǎo)致的了。
先說(shuō)結(jié)論吧:@PathVariable可以使請(qǐng)求參數(shù)動(dòng)態(tài)的綁定到URL上,但是如果請(qǐng)求參數(shù)中包含特殊字符,比如 /,就可能導(dǎo)致Spring匹配到一個(gè)錯(cuò)誤的URL,或者匹配不到合適的URL。
復(fù)現(xiàn)
下面,我用一個(gè)簡(jiǎn)單的偽代碼復(fù)現(xiàn)一下這個(gè)bug,與大家分析一下這個(gè)bug發(fā)生的原因,以及如何解決,最后順便再通過(guò)源碼加深一下印象。
如下,我們定義一個(gè)接口,并且通過(guò)@PathVariable將入?yún)?dòng)態(tài)的綁定到URL上。
然后我們測(cè)試一下這個(gè)接口:
正常情況下,我們輸入一個(gè)普通無(wú)特殊符號(hào)的參數(shù),控制臺(tái)也成功打印了出來(lái)。
但是業(yè)務(wù)參數(shù)往往是不可控的,比如當(dāng)參數(shù)變成“ hello/world”時(shí),代碼就不能正常執(zhí)行了。
大家可以從圖中看到,Spring將原本預(yù)期的URL:/demo/getVal/{val},解析成了/demo/getVal/hello/world。
而之所以測(cè)試同學(xué)最近才發(fā)現(xiàn)這個(gè)接口有問(wèn)題,也正是因?yàn)樯暇€(xiàn)之初并沒(méi)有遇到帶有/的參數(shù),所以接口看起來(lái)是正常的,直到最近在生產(chǎn)環(huán)境遇到了一個(gè)帶/的參數(shù)。
正確的做法是:將URL定義為/demo/getVal,然后將參數(shù)通過(guò)表單或者query的方式傳遞。
?解決的辦法很簡(jiǎn)單,相信有點(diǎn)經(jīng)驗(yàn)的同學(xué)都能很快將這個(gè)問(wèn)題修復(fù)。
但是知其然,更要知其所以然,順著這個(gè)問(wèn)題,我們探究一下Spring究竟是如何解析URL的。?
首先,我們找到Spring webmvc的包,在
org.springframework.web.servlet.handler包下找到AbstractHandlerMethodMapping類(lèi),這個(gè)類(lèi)就是會(huì)將我們定義的mapping和URL綁定起來(lái)。
這個(gè)類(lèi)中的lookupHandlerMethod方法,會(huì)查找當(dāng)前請(qǐng)求的最佳匹配處理程序方法,并且如果找到多個(gè)匹配項(xiàng),就選擇最佳匹配項(xiàng)。
分析這個(gè)方法,我們可以得到這樣3個(gè)匹配步驟:
1、根據(jù)Path精準(zhǔn)匹配
2、如果精準(zhǔn)匹配沒(méi)有成功,就開(kāi)始模糊匹配
3、如果模糊匹配還匹配不上,就返回null
至此,一個(gè)URL解析的過(guò)程就完畢了。單看源碼可以發(fā)現(xiàn),邏輯其實(shí)并不復(fù)雜,就是一個(gè)按照規(guī)則不斷匹配的過(guò)程。
最后
總得來(lái)說(shuō),@PathVariable可以讓我們開(kāi)發(fā)接口的時(shí)候省去一些功夫,但是需要注意到,如果綁定的參數(shù)帶有特殊字符,就有可能導(dǎo)致非預(yù)期的bug。
一般來(lái)說(shuō),@PathVariable比較適合綁定整型的參數(shù),如果是字符串類(lèi)的參數(shù),建議大家還是通過(guò)表單或json的方式傳參。