/和/*的區別記不住？我的答案保你終身難忘
本文轉載自微信公眾號「BAT的烏托邦」，作者YourBatman 。轉載本文請聯系BAT的烏托邦公眾號。
前言
你好，我是YourBatman。
這次的標題??吹得有點大，倍感壓力。不過沒關系，畢竟吹牛不用上睡，也不犯法。在信息大爆炸的時代，連技術圈的標題黨也不少啦：
- 30分鐘教你手擼一個ORM框架。其實就一個反射注解拼接字符串
- 5分鐘教你玩轉Docker。額，5分鐘后包就業嗎?
- 玩轉億級流量高并發緩存方案。全國(乃至全球)能達如此流量級別的屈指可數，你確定?
- ...
我標榜自己從不標題黨，是的這次也不例外。本文將分析/和/*的區別這個老生常談的問題，看別的博文總是看了忘忘了看，本文不同的是，關于此問題這一篇文章就夠了，它將成為你的永久記憶(一不小心又吹牛了??)
本文提綱
版本約定
- JDK：8
- Servlet：4.x
- tomcat：9.x
正文
什么樣的答案終身難忘?學生時代關于記憶經常能聽見兩種論調：
死記硬背：見效快，但也忘得快，且一般不會靈活運用(指標不治本)
理解性記憶：見效慢，但記憶持久且會靈活運用(治標又治本)
如果是你，你愿意pick哪種?
正所謂授人以魚不如授人以漁，后者方能形成永久記憶。不謀而合，本文將采用后種講述方式，幫你記憶持久化。
關于/和/*的區別這個問題，依稀記得2015年我自學那會就能把它倆搞得明明白白，并且通過理解形成了“永久記憶”，所以至那會其就從來沒有犯過迷糊，難道我就這么重視基礎么(md，又在吹牛。。。)
點撥“市面上”的錯誤答案
如果用谷歌百度一下關鍵字：/和/*的區別，搜索出來的答案不客氣的說，基本全錯!!! 錯誤的姿勢基本還一模一樣，原因你懂的。
各種錯誤case，且聽我娓娓道來。搜集了下有如下4種主流答案，一一點撥。
環境說明：使用原生Servlet，war包方式部署至外置Tomcat作為服務器，端口號8080，context-path為：appcontext
1、/用于Servlet，/*用于Filter
反例：
- @WebFilter(urlPatterns = {"/*"})
- public class FakeServlet extends HttpServlet {
- @Override
- protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
- System.out.println("FakeServlet收到請求：" + req.getRequestURI());
- }
- }
啟動服務器，瀏覽器訪問：http://localhost:8080/appcontext/api/demo1，控制臺輸出：
- FakeServlet收到請求：/appcontext/api/demo1
一般來講/確實用于Servlet，/*用于Filter，但并不代表這是正確的。
說明：Filter路徑模式使用/無效
2、/不會匹配.jsp請求，而/*可以匹配到.jsp請求
這個結論表面上看沒有問題，但是往深了想一步，是否能夠推導出這個結論：“/不會匹配.html請求，而/*可以匹配到.html請求”。試試看：
- @WebServlet(urlPatterns = {"/"})
- public class FakeServlet extends HttpServlet {
- @Override
- protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
- System.out.println("FakeServlet收到請求：" + req.getRequestURI());
- }
- }
- @WebFilter(urlPatterns = {"/*"})
- public class FakeFilter extends HttpFilter {
- @Override
- protected void doFilter(HttpServletRequest req, HttpServletResponse res, FilterChain chain) throws IOException, ServletException {
- System.out.println("FakeFilter收到請求：" + req.getRequestURI());
- super.doFilter(req, res, chain);
- }
- }
啟動服務器，瀏覽器訪問：http://localhost:8080/appcontext/api/demo1.jsp，控制臺輸出：
- FakeFilter收到請求：/appcontext/api/demo1.jsp
servlet并未匹配上，似乎符合此結論：/不會匹配.jsp請求，而/*可以。
瀏覽器再訪問：http://localhost:8080/appcontext/api/demo1.html，控制臺輸出：
- FakeFilter收到請求：/appcontext/api/demo1.html
- FakeServlet收到請求：/appcontext/api/demo1.html
Filter和Servlet都匹配成功，破功了吧!
所以說，局限于該回答本身沒有問題，而問題在于.jsp后綴是一種特殊的請求，拿特殊案例當做通用結論肯定是站不住腳的。
3、/*匹配范圍比/大
通過本文下面的講解你就會知道：/屬于最大的的匹配范圍，而/*恰好是范圍和/一樣了而已，但/*的優先級比/高，并不是它的匹配范圍比/大。
4、/匹配所有url(路徑+后綴)，/*只匹配路徑型
用一句話反駁：/*也能匹配上/api/demo1.html這種后綴型url(其實上面已經給出示例了)
這4個結論搜索排名非常靠前，不知誤導了多少小朋友呀。與其每次將信將疑，倒不如花點時間寫代碼自己做個試驗來得靠譜。我一向推崇的代碼多動手，人云亦云不如自己來上一發。
帶著這幾個?結論，接下來開始發大招啦：從根本上帶你理解Servlet規范的URL匹配機制，從而理解到/和/*的區別，授之以漁讓你終身難忘。
Servlet的urlPatterns路徑映射
說明：本文所指的Servlet是廣義的(規范)，所以也包含Filter的urlPatterns
Servlet/Filter是服務端的一段小程序，用于處理Http請求。每個Servlet可以映射1個or多個路徑，在xml時代這么寫(url-pattern標簽可寫多個)：
- <servlet-mapping>
- <servlet-name>Demo1Servlet</servlet-name>
- <url-pattern>/api/demo1</url-pattern>
- <url-pattern>/api/demo2</url-pattern>
- </servlet-mapping>
@WebServlet注解方式這么寫：
- @WebServlet(urlPatterns = {"/api/demo1", "/api/demo2"})
- public class Demo1Servlet extends HttpServlet { ... }
此時，該Servlet就能處理這兩種 URL了。
問題來了，如果希望本Servlet處理某一類請求，該怎么破呢?
一類請求顯然是無法一一枚舉出來的，這時就需要用到Servlet的模式匹配了。urlPatterns除了寫字面量的字符串，還支持pattern模式的字符串(從該屬性的命名你應該也能看出來)。
接下來聚焦于Servlet的匹配方式展開詳細講解，這是本文的核心內容。
Servlet四種匹配方式
在Servlet規范中一共約定了四種匹配方式，無一例外，每種方式都非常重要和常用，下面逐一介紹。
1. 精確匹配
顧名思義，urlPatterns是個無通配符的精確字符串，如：
- @WebServlet(urlPatterns = {"/api/demo1", "/api/demo2"}) // 精確匹配
- public class UrlPatternDemoServlet extends HttpServlet {
- @Override
- protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
- System.out.printf("收到請求：%s ServletPath:%s PathInfo:%s\n", req.getRequestURI(), req.getServletPath(), req.getPathInfo());
- }
- }
打印里輸出servletPath和pathInfo信息，讓日志更具對比性
瀏覽器訪問http://localhost:8080/appcontext/api/demo1和/api/demo2均能收到該請求，控制臺分別打印：
- 收到請求：/appcontext/api/demo1 ServletPath:/api/demo1 PathInfo:null
- 收到請求：/appcontext/api/demo2 ServletPath:/api/demo2 PathInfo:null
2. 路徑匹配
pattern規則：以/開頭，且以/*結尾。如：
- @WebServlet(urlPatterns = {"/api/*", "/*"}) // 路徑匹配
- public class UrlPatternDemoServlet extends HttpServlet {
- @Override
- protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
- // 同上
- }
- }
瀏覽器訪問http://localhost:8080/appcontext/api/demo1，控制臺輸出(匹配的/api/*)：
- 收到請求：/appcontext/api/demo1 ServletPath:/api PathInfo:/demo1
訪問http://localhost:8080/appcontext/apiapi/demo1，控制臺輸出(匹配的/*：
- 收到請求：/appcontext/apiapi/demo1 ServletPath: PathInfo:/apiapi/demo1
關注點：當匹配上/*模式時，ServletPath的值為空串，但PathInfo的值更為“豐富”了。
3. 后綴名匹配
patten規則：以*.開頭(注意是開頭，所以/api/*.jsp這么寫是非法的)。如：
- @WebServlet(urlPatterns = {"*.jsp", "*.*"}) // 后綴名匹配
- public class UrlPatternDemoServlet extends HttpServlet {
- @Override
- protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
- // 同上
- }
- }
訪問http://localhost:8080/appcontext/api/demo1，結果404，因為沒有后綴嘛;訪問http://localhost:8080/appcontext/api/demo1.jsp，控制臺輸出(匹配*.jsp)：
- 收到請求：/appcontext/api/demo1.jsp ServletPath:/api/demo1.jsp PathInfo:null
訪問http://localhost:8080/appcontext/api/demo1.servlet，結果404，因為urlPatterns里沒有匹配.servlet后綴的模式;訪問http://localhost:8080/appcontext/api/demo1.，結果404，原因同上 訪問http://localhost:8080/appcontext/api/demo1.*，控制臺打印(匹配*.*)：
- 收到請求：/appcontext/api/demo1.* ServletPath:/api/demo1.* PathInfo:null
發現沒，這種匹配方式還蠻“特殊”的，需要注意這兩點：
該模式以*.開頭，后面的均是常量，即使是*也是常量。比如*.*匹配的后綴必須是.*而不能是其它
該匹配方式下，pathInfo永遠是null，servletPath永遠是“全部”
4. 缺省匹配
pattern規則：固定值/。如：
想一想，這不就是我們熟悉的DispatcherServlet的匹配路徑么?
- @WebServlet(urlPatterns = "/") // 缺省匹配
- public class UrlPatternDemoServlet extends HttpServlet {
- @Override
- protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
- // 同上
- }
- }
這個時候匹配任意路徑。
訪問http://localhost:8080/appcontext，控制臺打印：
- 收到請求：/appcontext/ ServletPath:/ PathInfo:null
訪問http://localhost:8080/appcontext/api/demo1，控制臺打印：
- 收到請求：/appcontext/api/demo1 ServletPath:/api/demo1 PathInfo:null
訪問http://localhost:8080/appcontext/api/demo1.html，控制臺打印：
- 收到請求：/appcontext/api/demo1.html ServletPath:/api/demo1.html PathInfo:null
此匹配規則下，pathInfo永遠是null，servletPath永遠是“全部”。
關于pathInfo：pathInfo只有當Servlet是路徑匹配時，才有值。其它情況永遠為null
URL匹配注意事項
Servlet對URL的匹配既不是Ant風格，也不是Regex。特殊符號只有單個的*，且使用位置有強約束，切忌想當然的隨意拼湊。
舉例兩種典型的錯誤理解，應該能幫助到你：
- /api/*.jsp：該urlPatterns是非法的，啟動時會報錯“IllegalArgumentException: servlet映射中的[/api/*.jsp]無效”。原因為：
- 若當路徑匹配，/*后面不能再有任何東西
- 若當后綴名匹配，*.必須是最前面
- /api/*/demo：這個urlPatterns是合法的。只不過它屬于精確匹配，也就是說別看它中間有*，仍舊有且僅能匹配/api/*/demo這個請求路徑
匹配順序
有時候一個URL會被多個urlPatterns所匹配，這時誰優先呢?
Servlet同樣遵循“國際慣例”：越精確越優先，越模糊越靠后。站在pattern模式的角度換句話講就是：范圍越小越優先，范圍越大越靠后。
因此Servlet四種匹配方式順序按范圍從小到大(優先級從高到底)排序為：精確匹配 > 路徑匹配 > 后綴名匹配 > 缺省匹配。
/和/*的區別
終于，來到了今天的主菜。
從上至下的閱讀到這里，再看這個問題，是不是覺得答案已經浮出水面?那么，最后我還是來總結一下它倆的異同點：
相同點
絕大部分場景下具有相同的表現：匹配所有。
不同點
就是由于它們的相同點(如此相似)，所以才讓我們難以區分。
關于/：
- servlet中特殊的匹配模式(用在Filter中無效)，
- 因為是缺省匹配代表匹配所有路徑，所以只可能存在一個實例(若存在多個就覆蓋)
- 優先級最低(兜底)，這是和/*的最大區別。它不會覆蓋任何其它的url-pattern，只會覆蓋Servlet容器(如Tomcat)內建的DefaultServlet
關于/*：
- 屬于4中匹配模式中的路徑匹配，可用于Servlet和Filter
- 優先級很高(僅次于精確匹配)。所以它會覆蓋所有的后綴名匹配，從而很容易引起404問題，所以這種模式的“傷害性”是非常強的，一般有且僅用在Filter上
DispatcherServlet不攔截.jsp請求根因分析
/只能用于Servlet上，/*一般只用于Filter上。
大家熟悉的Spring MVC的DispatcherServlet的匹配路徑默認就是/，它會攔截各種各樣的請求，諸如下面這種請求都會攔截：
- /api/demo1
- /html/demo1.html
- /static/main.js
但是，它不會攔截/api/demo1.jsp這種以.jsp結尾的請求。據此現象就出現了：/不攔.jsp請求而/*攔截(/*的范圍比/大)這種“錯誤”言論。
下面告訴你此現象的根因：Servlet容器(如Tomcat)內置有專門匹配.jsp這種請求的Servlet處理器，如下圖所示：
而后綴名匹配優先級高于缺省匹配，所以.jsp結尾的請求不會被DispatcherServlet所“截胡”而是交給了JspServlet處理。
有了這波分析后，就問你，是不是就不用死記答案了?是不是就終身難忘啦?
總結
Servlet的urlPatterns匹配方式是學習Java Web的重要一環，也是深入理解Spring MVC原理的大門，畢竟Spring MVC依舊是做業務開發的首選，而且還會持續很久、很久。
本文對Servlet的匹配方式做了全覆蓋講解，包括：
- 四種匹配方式
- 匹配順序(優先級)
- Servlet和Filter匹配的區別
- 模式匹配中/和/*區別的根本原因
通過本文希望能讓你不再被Servlet的模式匹配所困擾，更不要被一些似可非可的結論所迷惑，搖擺不定時大不了編碼驗證一下嘛。
本文通過授人以漁的方式道出/和/*的區別，期待能成為你的永久記憶，我做到了嗎?
