前言

前天工作中遇到了這樣一個問題，我在接口的參數封裝了一個pojo,這是很常見的，當參數一多，慣性的思維就是封裝一個pojo.那么在參數前有很多注解可以添加，比如：@requestparam,@requestbody,@pathvariable等。我的理解是這樣的，首先我先申明，我并是沒有看過源碼，只是憑經驗理解。@requestparam試用于get請求，參數在http的header中的url上,具體放在？后面以key=value的形式存在。@requestbody適用于post請求中參數在http的body中。@pathvariable比較特別是restful的寫法，把參數放在url上，不用問號區分是參數還是url。也許我這樣說不是很準確。但我通常也是這么用的。與此同時，還有一種常見的寫法，就是參數前不加注解，比如參數是基本類型的不加@requestparam，參數是bean的不加requestbody，也能被springmvc解析得到。我的接口被小組長看到之后他叫我去掉這個@requestbody，因為后端加上這個之后，前端的ajax請求需要顯示的聲明content-type:"application/json"，才能被springmvc解析得到，這樣似乎多做了一件不必要的事情。雖然我按照他的要求去掉了，但是我覺得我得弄清楚這到底是怎么回事，加與不加到底有什么區別，對性能有什么影響，或者各自的最佳適用場景，除了百度，還得問問大神。

spring mvc接口參數解析的過程

首先我自己慢慢的通過debug研究了一下源碼。在不添加任何注解的情況下：

在開發的過程中consumes和produces一般都沒有加，按道理應該要加上，因為可以減少對接口的查找范圍。這是一個簡單的demo,我只是需要他來檢查springmvc接收請求的流程。

首先在tomcat啟動之后，所有controller類中的請求路徑也就是@requestmapping隨著controller這個bean加載到了spring的容器中。頁面請求過來之后找到dispatcherservlet這個servlet,請求走到servlet之后大家都知道servlet有兩種初始化方式，一種是隨著立即加載，一種是延遲加載，但是無論怎樣，都是只調用一次init方法，然后再以后每次都會直接調用service方法，當tomcat關閉之后servlet的destroy方法被調用生命周期就結束了。所以springmvc是對servlet的封裝就必定要繼承service方法，dispatcherservlet也就是dodispatch這個方法。這個方法中通過httpservletrequest對象獲得請求路徑也就是/notjson,然后與容器中的所有url對比，最終取得controller中的接口所在。找到了接口自然就知道了接口的參數，我這里就是display,為了方便簡單，display中只有兩個參數，就是下面ajax請求中的兩個。

springmvc會通過反射的方式獲取到pojo中的屬性。在這個過程中首先springmvc會先聲明一個數組，這個數組的大小是參數的個數，我這里只有一個，其實我相信很多人會和我遇到相同的問題就是，當參數中同時存在bean和基本類型的參數，springmvc將怎么解析，這個我遇到過幾次，在沒有看源碼的情況下，把基本類型也封裝到bean中去了，讓前端把屬性也寫在一個對象中。當然我相信這個不是每個人都能接受的做法，我們都希望搞清楚他究竟是怎樣解析的，到時候我們就可以任意擺弄了。下面是反射過程，將我的pojo反射之后獲得里面的屬性和方法。解析了參數之后，為參數賦值。這里也許是最重要的地方了。究竟是怎么賦值的。

從這個方法debug了解到，name為display,也就是pojo類名的小寫，這里不知道為什么springmvc做了這個處理（以后再看）。attribute為帶有age和name的對象。不過此時都是null。webdatabinding用于從web請求參數到javabean對象的數據綁定的特殊databinder。接上圖bindrequestparameters這個方法，跟進去會發現一個很熟悉的地方就是下圖，通過string[] values = request.getparametervalues(paramname);獲得參數名，這個是servlet的獲取參數方法，那么就可以知道請求的參數的屬性名和屬性值。

接下來可想而知就是把這個參數名name換成bean的屬性name，參數名age換成屬性名age。再跟到這個地方，這個oragina就是上面serclet拿到的屬性名值對，把這個map在這轉化成propertyvalue。（propertyvalue是用于保存單個bean屬性的信息和值的對象。 在此處使用對象，而不是僅將所有屬性存儲在由屬性名稱鍵入的映射中，允許更靈活，并且能夠以優化的方式處理索引屬性等。請注意，該值不需要是最終所需的類型：beanwrapper實現應該處理任何必要的轉換，因為此對象不知道它將應用于哪些對象。)，如此一來就有兩個propertyvalue對象了。

轉化的時候會忽略不知道的屬性

上圖是具體轉化的方法，方法比較長。下面一句直接給bean賦值。從這個過程來看。只要前端的json對象的屬性和后端的bean屬性一樣，ajax不寫content-type,用默認的application/x-www-form-urlencoded; charset=utf-8，就能直接賦值。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對服務器之家的支持。

原文鏈接：https://www.cnblogs.com/007tangtao/p/9251861.html