[[406999]]

前言

你好，我是YourBatman。

依稀記得3年前的在“玩”Spring WebFlux的時(shí)候，看到PathPattern在AbstractHandlerMapping中起到了重要作用：用于URL的匹配。當(dāng)時(shí)就很好奇：這一直不都是AntPathMatcher的活嗎?

于是乎我就拿出了自己更為熟悉的Spring WebMvc對(duì)于類進(jìn)行功能比對(duì)，發(fā)現(xiàn)PathPattern扮演的角色和AntPathMatcher一毛一樣，所以當(dāng)時(shí)也就沒去深入研究啦。

正所謂念念不忘必有回響。時(shí)隔3年最近又回到搞WebFlux了，欠下的債總歸要還呀，有必要把PathPattern深入解讀，畢竟它是Spring5在路徑解析器方面的新寵，貫穿WebFlux上下。重點(diǎn)是號(hào)稱比AntPathMatcher擁有更好的使用體驗(yàn)以及更快的匹配效率，咦，勾起了興趣了解一下~

正值周末，說干就干。

所屬專欄

• 點(diǎn)撥-Spring技術(shù)棧

本文提綱

版本約定

• JDK：8
• Spring Framework：5.3.x

正文

PathPattern是Spring5新增的API，所在包：org.springframework.web.util.pattern.PathPattern，所屬模塊為spring-web?？梢娝鼘閃eb設(shè)計(jì)的“工具”。

不同于AntPathMatcher是一個(gè)“上帝類”把所有活都干了，新的路徑匹配器圍繞著PathPattern擁有一套體系，在設(shè)計(jì)上更具模塊化、更加面向?qū)ο?，從而擁有了更好的可讀性和可擴(kuò)展性。

下面深入了解下該技術(shù)體系下的核心元素。主要有：

• PathElement：路徑元素。一個(gè)URL模板根據(jù)/可以拆分成N多個(gè)路徑元素對(duì)象
• PathContainer：URL的結(jié)構(gòu)化表示。一個(gè)URL對(duì)應(yīng)一個(gè)PathContainer對(duì)象實(shí)例
• PathPattern：路徑解析的模式。路徑模式匹配器的最核心API
• PathPatternParser：將一個(gè)String類型的模式解析為PathPattern實(shí)例，這是創(chuàng)建PathPattern實(shí)例的唯一方式

PathElement：路徑元素

顧名思義，它表示路徑節(jié)點(diǎn)。一個(gè)path會(huì)被解析成N多個(gè)PathElement節(jié)點(diǎn)。

核心屬性：

// Since: 5.0 
abstract class PathElement { 
 
 protected final int pos; 
 protected final char separator; 
 @Nullable 
 protected PathElement next; 
 @Nullable 
 protected PathElement prev; 
} 

• pos：該節(jié)點(diǎn)在path里的起點(diǎn)位置
• separator：該path使用的分隔符
• next：后節(jié)點(diǎn)，可以為null(如最后一個(gè)節(jié)點(diǎn))
• prev：前節(jié)點(diǎn)，可以為null(如第一個(gè)節(jié)點(diǎn))

所有的PathElement之間形成鏈狀結(jié)構(gòu)，構(gòu)成一個(gè)完整的URL模板。

Tips：我個(gè)人意見，并不需要太深入去了解PathElement內(nèi)部的具體實(shí)現(xiàn)，在宏觀角度了解它的定義，然后認(rèn)識(shí)下它的子類實(shí)現(xiàn)不同的節(jié)點(diǎn)類型即可

它有如下子類實(shí)現(xiàn)：

SeparatorPathElement

分離器元素。代表用于分離的元素(默認(rèn)是/，也可以是.)

@Test 
public void test1() { 
    PathPatternParser parser = new PathPatternParser(); 
    PathPattern pathPattern = parser.parse("/api/v1"); 
    System.out.println(pathPattern); 
} 

斷點(diǎn)調(diào)試查看解析后的pathPattern變量擁有的元素情況：

可以看到這是標(biāo)準(zhǔn)的鏈?zhǔn)浇Y(jié)構(gòu)嘛，這種關(guān)系用圖畫出來就是這樣子：

其中綠色的/都是SeparatorPathElement類型，藍(lán)色都是LiteralPathElement字面量類型。將一個(gè)Pattern拆解成為了一個(gè)個(gè)的Element對(duì)象，后面就可以方便的面向?qū)ο缶幊?，大大增加了可讀性、降低出錯(cuò)的概率。

說明：由于這是第一個(gè)元素，所以才舉了個(gè)實(shí)際的代碼示例輔助理解。下面的就只需描述概念啦，舉一反三即可~

WildcardPathElement

通配符元素。如：/api/*/yourbatman

說明：在路徑中間它至少匹配1個(gè)字符(//不行，/ /可行)，但在路徑末尾可以匹配0個(gè)字符

SingleCharWildcardedPathElement

單字符通配符元素。如：/api/your??tman

說明：一個(gè)?代表一個(gè)單字通配符，若需要適配多個(gè)用多個(gè)?即可

WildcardTheRestPathElement

通配剩余路徑元素。如：/api/yourbatman/**

說明：**只能放在path的末尾，這才是rest剩余的含義嘛

CaptureVariablePathElement

將一段路徑作為變量捕獲的路徑元素。如：/api/yourbatman/{age}

說明：{age}就代表此元素類型被封裝進(jìn)來

CaptureTheRestPathElement

捕獲路徑其余部分的路徑元素。如：/api/yourbatman/{*restPath}

說明：若待匹配的路徑是/api/yourbatman/a/b/c，那么restPath=a/b/c

LiteralPathElement

字面量元素。不解釋~

RegexPathElement

正則表達(dá)式元素。如：api/*_*/*_{age}說明：*_*和*_{age}都會(huì)被解析為該元素類型，這種寫法是從AntPathMatcher里派生來過的(但不會(huì)依賴于AntPathMatcher)

總之：任何一個(gè)字符串的pattern最終都會(huì)被解析為若干段的PathElement，這些PathElement以鏈?zhǔn)浇Y(jié)構(gòu)連接起來用以表示該pattern，形成一個(gè)對(duì)象數(shù)據(jù)。不同于AntPathMatcher的純字符串操作，這里把每一段都使用對(duì)象來描述，結(jié)構(gòu)化的表示使得可讀性更強(qiáng)、更具靈活性，甚至可以獲得更好的性能表現(xiàn)。

PathContainer：URL的結(jié)構(gòu)化表示

和PathPattern類似，待匹配的path的每一段都會(huì)表示為一個(gè)元素并保存其元數(shù)據(jù)信息。也就是說：每一個(gè)待匹配的URL路徑都會(huì)被解析為一個(gè)PathContainer實(shí)例。

PathContainer雖然是個(gè)接口，但我們無需關(guān)心其實(shí)現(xiàn)，類同于Java 8的java.util.stream.Collector接口使用者無需關(guān)心其實(shí)現(xiàn)一樣。因?yàn)樘峁┝遂o態(tài)工具方法用于直接生成對(duì)應(yīng)實(shí)例。體驗(yàn)一把：

@Test 
public void test2() { 
    PathContainer pathContainer = PathContainer.parsePath("/api/v1/address", PathContainer.Options.HTTP_PATH); 
    System.out.println(pathContainer); 
} 

debug模式運(yùn)行，查看pathContainer對(duì)象詳情：

這和解析為PathPattern的結(jié)構(gòu)何其相似(不過這里元素們是通過有序的集合組織起來的)。對(duì)比看來，拍腦袋應(yīng)該能夠猜到何新版的匹配效率會(huì)更高了吧。

補(bǔ)充說明：

• value和valueToMatch的區(qū)別：value是原值，valueToMatch是(處理過的，比如已解碼的)最終參與匹配的值
• parameters代表路徑參數(shù)。若希望它有值只需使用;號(hào)分隔填值即可。如：/api;abc/v1，此參數(shù)一般都用不著

因?yàn)镠ttp中是允許這樣攜帶參數(shù)的，但是目錄(.形式)就不能這么寫啦

PathPattern：路徑解析的模式

表示解析路徑的模式。包括用于快速匹配的路徑元素鏈，并累積用于快速比較模式的計(jì)算狀態(tài)。它是直接面向使用者進(jìn)行匹配邏輯的最重要API，完成match操作。

PathPattern所在包是org.springframework.web.util.pattern.PathPattern，位于spring-web模塊，專為web(含webmvc和webflux)設(shè)計(jì)的全新一套路徑匹配API，具有更高的匹配效率。

認(rèn)識(shí)下它的成員屬性：

// Since: 5.0 
public class PathPattern implements Comparable<PathPattern> { 
 
 // pattern的字符串形式 
 private final String patternString; 
 // 用于構(gòu)建本實(shí)例的解析器 
 private final PathPatternParser parser; 
 // 分隔符使用/還是.，默認(rèn)是/ 
 private final PathContainer.Options pathOptions; 
 // 如果pattern里結(jié)尾沒/而待匹配的有，仍然讓其匹配成功（true），默認(rèn)是true 
 private final boolean matchOptionalTrailingSeparator; 
 // 是否對(duì)大小寫敏感，默認(rèn)是true 
 private final boolean caseSensitive; 
 // 鏈?zhǔn)浇Y(jié)構(gòu)：表示URL的每一部分元素 
 @Nullable 
 private final PathElement head; 
 
 private int capturedVariableCount; 
 private int normalizedLength; 
 private boolean endsWithSeparatorWildcard = false; 
 private int score; 
 private boolean catchAll = false; 
 
} 

以上屬性是直接讀取，下面這些個(gè)是計(jì)算出來的，比較特殊就特別照顧下：

• capturedVariableCount：在這個(gè)模式中捕獲的變量總數(shù)。也就是{xxx}或者正則捕獲的總數(shù)嘍
• normalizedLength：通配符批到的變量長度的總和(關(guān)于長度的計(jì)算有個(gè)約定：如?是1，字面量就是字符串長度)，這個(gè)變量對(duì)提升匹配速度有幫助
• endsWithSeparatorWildcard：標(biāo)記該模式是否以隔離符或者通配符*結(jié)尾
• score：分?jǐn)?shù)用于快速比較該模式。不同的模式組件被賦予不同的權(quán)重。分?jǐn)?shù)越低越具體，如：捕獲到的變量分?jǐn)?shù)值為1，通配符值是100
• catchAll：該pattern是否以**或者{*xxx}結(jié)尾

score、catchAll等標(biāo)記用于加速匹配的速度，具體體現(xiàn)在PathPattern.SPECIFICITY_COMPARATOR這個(gè)比較器上，這是PathPattern速度比AntPathMatcher快的根因之一

值得注意的是：所有屬性均不提供public的set方法，也就是說PathPattern實(shí)例一旦創(chuàng)建就是只讀(不可變)實(shí)例了。

快速創(chuàng)建缺省的實(shí)例

上面了解到，PathPattern的構(gòu)造器不是public的，所以有且僅能通過PathPatternParser創(chuàng)建其實(shí)例。然而，為快速滿足絕大多數(shù)場(chǎng)景，Spring還提供了一種快速創(chuàng)建缺省的PathPattern實(shí)例的方式：

PathPatternParser提供一個(gè)全局共享的、只讀的實(shí)例用于快速創(chuàng)建缺省的PathPattern實(shí)例，類似于實(shí)例工廠的作用。畢竟絕大部分場(chǎng)景下用PathPattern的缺省屬性即可，因此有了它著實(shí)方便不少。

注意：雖然該P(yáng)athPatternParser實(shí)例是全局共享只有1個(gè)，但是，創(chuàng)建出來的PathPattern可是不同實(shí)例哦(基本屬性都一樣而已)

代碼示例

PathPattern的匹配方式和AntPathMatcher基本保持一致：使用的基于Ant風(fēng)格模式匹配。

但是發(fā)現(xiàn)沒，這里不再強(qiáng)調(diào)Ant字樣，也許Spring覺得Ant的概念確實(shí)已廉頗老矣?不符合它緊跟潮流的身份?

相比于AntPathMatcher，PathPattern主要有兩處地方不一樣：

說明：PathPattern只支持兩種分隔符(/和.)，而AntPathMatcher可以隨意指定。雖然這也是不同點(diǎn)，但這一般無傷大雅所以就不單獨(dú)列出了

1. 新增{*pathVariable}語法支持

這是PathPattern新增的“語法”，表示匹配余下的path路徑部分并將其賦值給pathVariable變量。

@Test 
public void test1() { 
    System.out.println("======={*pathVariable}語法======"); 
    PathPattern pattern = PathPatternParser.defaultInstance.parse("/api/yourbatman/{*pathVariable}"); 
 
    // 提取匹配到的的變量值 
    System.out.println("是否匹配：" + pattern.matches(PathContainer.parsePath("/api/yourbatman/a/b/c"))); 
    PathPattern.PathMatchInfo pathMatchInfo = pattern.matchAndExtract(PathContainer.parsePath("/api/yourbatman/a/b/c")); 
    System.out.println("匹配到的值情況：" + pathMatchInfo.getUriVariables()); 
} 
 
======={*pathVariable}語法====== 
是否匹配：true 
匹配到的值情況：{pathVariable=/a/b/c} 

在沒有PathPattern之前，雖然也可以通過/**來匹配成功，但卻無法得到匹配到的值，現(xiàn)在可以了!

和**的區(qū)別

我們知道/**和/{*pathVariable}都有匹配剩余所有path的“能力”，那它倆到底有什么區(qū)別呢?

1. /**能匹配成功，但無法獲取到動(dòng)態(tài)成功匹配元素的值
2. /{*pathVariable}可認(rèn)為是/**的加強(qiáng)版：可以獲取到這部分動(dòng)態(tài)匹配成功的值

正所謂一代更比一代強(qiáng)嘛，如是而已。

和**的優(yōu)先級(jí)關(guān)系

既然/**和/{*pathVariable}都有匹配剩余path的能力，那么它倆若放在一起，優(yōu)先級(jí)關(guān)系是怎樣的呢?

妄自猜測(cè)沒有意義，跑個(gè)案例一看便知：由于PathPattern實(shí)現(xiàn)了比較器接口，因此本例利用SortedSet自動(dòng)排序即可，排第一的證明優(yōu)先級(jí)越高

@Test 
public void test2() { 
    System.out.println("======={*pathVariable}和/**優(yōu)先級(jí)======"); 
    PathPattern pattern1 = PathPatternParser.defaultInstance.parse("/api/yourbatman/{*pathVariable}"); 
    PathPattern pattern2 = PathPatternParser.defaultInstance.parse("/api/yourbatman/**"); 
 
    SortedSet<PathPattern> sortedSet = new TreeSet<>(); 
    sortedSet.add(pattern1); 
    sortedSet.add(pattern2); 
 
    System.out.println(sortedSet); 
} 
 
======={*pathVariable}和/**優(yōu)先級(jí)====== 
[/api/yourbatman/**, /api/yourbatman/{*pathVariable}] 

測(cè)試代碼的細(xì)節(jié)：故意將/{*pathVariable}先放進(jìn)set里面而后放/**，但最后還是/**在前。

結(jié)論：當(dāng)二者同時(shí)出現(xiàn)(出現(xiàn)沖突)時(shí)，/**優(yōu)先匹配。

2. 禁用中間**語法支持

在上篇文章對(duì)AntPathMatcher的詳細(xì)分析文章中，我們知道是可以把/**放在整個(gè)URL中間用來匹配的，如：

@Test 
public void test4() { 
    System.out.println("=======**:匹配任意層級(jí)的路徑/目錄======="); 
    String pattern = "/api/**/yourbatman"; 
 
    match(1, MATCHER, pattern, "/api/yourbatman"); 
    match(2, MATCHER, pattern, "/api//yourbatman"); 
    match(3, MATCHER, pattern, "/api/a/b/c/yourbatman"); 
} 
 
=======**:匹配任意層級(jí)的路徑/目錄======= 
1 match結(jié)果：/api/**/yourbatman 【成功】 /api/yourbatman 
2 match結(jié)果：/api/**/yourbatman 【成功】 /api//yourbatman 
3 match結(jié)果：/api/**/yourbatman 【成功】 /api/a/b/c/yourbatman 

與AntPathMatcher不同，**僅在模式末尾受支持。中間不被允許了，否則實(shí)例創(chuàng)建階段就會(huì)報(bào)錯(cuò)：

@Test 
public void test3() { 
    System.out.println("=======/**放在中間語法======"); 
    PathPattern pattern = PathPatternParser.defaultInstance.parse("/api/**/yourbatman"); 
 
    pattern.matches(PathContainer.parsePath("/api/a/b/c/yourbatman")); 
} 
 
=======/**放在中間語法====== 
org.springframework.web.util.pattern.PatternParseException: No more pattern data allowed after {*...} or ** pattern element 
 at org.springframework.web.util.pattern.InternalPathPatternParser.peekDoubleWildcard(InternalPathPatternParser.java:250) 
 ... 

從報(bào)錯(cuò)中還能看出端倪：不僅**，{*xxx}也是不能放在中間而只能是末尾的

PathPattern這么做的目的是：消除歧義。

那么問題來了，如果就是想匹配中間的任意層級(jí)路徑怎么做呢?答：首先這在web環(huán)境里有這樣需求的概率極小(PathPattern只適用于web環(huán)境)，若這依舊是剛需，那就只能蛻化到借助AntPathMatcher來完成嘍。

PathPattern對(duì)比AntPathMatcher

二者目前都存在于Spring技術(shù)棧內(nèi)，做著“相同”的事。雖說現(xiàn)在還鮮有同學(xué)了解到PathPattern，我認(rèn)為淘汰掉AntPathMatcher只是時(shí)間問題(特指web環(huán)境哈)，畢竟后浪總歸有上岸的一天。

但不可否認(rèn)，二者將在較長時(shí)間內(nèi)共處，那么它倆到底有何區(qū)別呢?了解一下

出現(xiàn)時(shí)間

AntPathMatcher是一個(gè)早在2003年(Spring的第一個(gè)版本)就已存在的路徑匹配器，而PathPattern是Spring 5新增的，旨在用于替換掉較為“古老”的AntPathMatcher。

功能差異

PathPattern去掉了Ant字樣，但保持了很好的向下兼容性：除了不支持將**寫在path中間之外，其它的匹配規(guī)則從行為上均保持和AntPathMatcher一致，并且還新增了強(qiáng)大的{*pathVariable}的支持。

因此在功能上姑且可認(rèn)為二者是一致的，極特殊情況下的不兼容除外。

性能差異

Spring官方說PathPattern的性能優(yōu)于AntPathMatcher，我抱著懷疑的態(tài)度做了測(cè)試，示例代碼和結(jié)果如下：

// 匹配的模板：使用一個(gè)稍微有點(diǎn)復(fù)雜的模板進(jìn)行測(cè)試private static final String pattern = "/api/your?atman/{age}/**";

// 匹配的模板：使用一個(gè)稍微有點(diǎn)復(fù)雜的模板進(jìn)行測(cè)試 
private static final String pattern = "/api/your?atman/{age}/**"; 

// AntPathMatcher匹配代碼：使用單例的PathMatcher，符合實(shí)際使用情況 
private static final PathMatcher MATCHER = new AntPathMatcher(); 
public static void antPathMatcher(String reqPath) { 
    MATCHER.match(reqPath); 
} 

// PathPattern代碼示例：這里的pattern由下面來定義 
private static final PathPattern PATTERN = PathPatternParser.defaultInstance.parse(pattern); 
public static void pathPattern(String reqPath) { 
    PATTERN.matches(PathContainer.parsePath(reqPath)); 
} 

匹配的測(cè)試代碼：

@Test 
public void test1() { 
    Instant start = Instant.now(); 
    for (int i = 0; i < 100000; i++) { 
        String reqPath = "/api/yourBatman/" + i + "/" + i; 
        antPathMatcher(reqPath); 
        // pathPattern(reqPath); 
    } 
    System.out.println("耗時(shí)(ms)：" + Duration.between(start, Instant.now()).toMillis()); 
} 

不斷調(diào)整循環(huán)次數(shù)，且各執(zhí)行三次，將結(jié)果繪制成如下表格：

測(cè)試機(jī)配置為：

循環(huán)100000次：

循環(huán)1000000次：

循環(huán)10000000次：

結(jié)論：PathPattern性能比AntPathMatcher優(yōu)秀。理論上pattern越復(fù)雜，PathPattern的優(yōu)勢(shì)越明顯。

最佳實(shí)踐

既然路徑匹配器有兩種方案，那必然有最佳實(shí)踐。Spring官方對(duì)此也是持有態(tài)度的：

Web環(huán)境

如果是Servlet應(yīng)用(webmvc)，官方推薦PathPattern(只是推薦，但默認(rèn)的依舊是AntPathMatcher哈)，相關(guān)代碼體現(xiàn)在PathPattern里：

// Since: 07.04.2003 
public abstract class AbstractHandlerMapping ... { 
  
 private UrlPathHelper urlPathHelper = new UrlPathHelper(); 
 private PathMatcher pathMatcher = new AntPathMatcher(); 
  
 ... 
  
 @Nullable 
 private PathPatternParser patternParser; 
 // Since: 5.3 
 public void setPatternParser(PathPatternParser patternParser) { 
  this.patternParser = patternParser; 
 } 
} 

注意：setPatternParser()從5.3版本開始才被加入，也就說雖然PathPattern從Spring 5就有了，但直到5.3版本才被加入到webmvc里，且作為可選(默認(rèn)依舊是AntPathMatcher)。換句話講：在Spring 5.3版本之前，仍舊只能用AntPathMatcher。

在WebMvc里啟用PathPattern

默認(rèn)情況下，Spring MVC依舊是使用的AntPathMatcher進(jìn)行路徑匹配的，那如何啟用效率更高的PathPattern呢?

通過上面源碼知道，就是要調(diào)用AbstractHandlerMapping的setPatternParser方法嘛，其實(shí)Spring為此是預(yù)留了擴(kuò)展點(diǎn)的，只需這么做即可：

/** 
 * 在此處添加備注信息 
 * 
 * @author YourBatman. <a href=mailto:yourbatman@aliyun.com>Send email to me</a> 
 * @site https://yourbatman.cn 
 * @date 2021/6/20 18:33 
 * @since 0.0.1 
 */ 
@Configuration(proxyBeanMethods = false) 
public class WebMvcConfiguration implements WebMvcConfigurer { 
 
    @Override 
    public void configurePathMatch(PathMatchConfigurer configurer) { 
        configurer.setPatternParser(PathPatternParser.defaultInstance); 
    } 
} 

如果是Reactor應(yīng)用(webflux)，那PathPattern就是唯一解決方案。這體現(xiàn)在org.springframework.web.reactive.handler.AbstractHandlerMapping：

// Since: 5.0 
public abstract class AbstractHandlerMapping... { 
 
 private final PathPatternParser patternParser; 
 ... 
 public AbstractHandlerMapping() { 
  this.patternParser = new PathPatternParser(); 
 } 
} 

webflux里早已不見AntPathMatcher的蹤影，因?yàn)閣ebflux是從Spring 5.0開始的，因此沒有向下兼容的負(fù)擔(dān)，直接全面擁抱PathPattern了。

結(jié)論：PathPattern語法更適合于web應(yīng)用程序，其使用更方便且執(zhí)行更高效。

非Web環(huán)境

嗯，如果認(rèn)真“聽課”了的同學(xué)就知道：非Web環(huán)境依舊有且僅有一種選擇，那便是AntPathMatcher，因?yàn)镻athPattern是專為Web環(huán)境設(shè)計(jì)，不能用于非Web環(huán)境。所以像上面資源加載、包名掃描之類的，底層依舊是交給AntPathMatcher去完成。

說明：由于這類URL的解析絕大多數(shù)情況下匹配一次(執(zhí)行一次)就行，所以微小的性能差異是無所謂的(對(duì)API來講收益較大)

可能有小伙伴會(huì)說：在Service層，甚至Dao層我也可以正常使用PathPattern對(duì)象呀，何解?這個(gè)問題就相當(dāng)于：HttpServletRequest屬于web層專用組件，但你依舊可以將其傳到Service層，甚至Dao層供以使用，在編譯、運(yùn)行時(shí)不會(huì)報(bào)錯(cuò)。但你可深入思考下，這么做合適嗎?

舉個(gè)生活上的例子：馬桶可以裝在衛(wèi)生間，也可以安裝在臥室的床旁邊，都能完成大小便功能，但你覺得這么做合適嗎?

Java這門語言對(duì)訪問權(quán)限的控制設(shè)計(jì)得還是很優(yōu)秀的，很多隔離性的問題在編譯器就能搞定。但有很多規(guī)范性做法是無法做到強(qiáng)約束的，只能依靠工程師自身水平。這就是經(jīng)驗(yàn)，也是區(qū)別初級(jí)工程師和高級(jí)工程師的重要因素。

總結(jié)

技術(shù)的日新月異，體現(xiàn)在一個(gè)個(gè)像PathPattern這個(gè)更好的API上。

Spring 5早在2017-09就已發(fā)布，可能是由于它“設(shè)計(jì)得過于優(yōu)秀”，即使大版本的發(fā)布也幾乎保持100%向下兼容，使得一般開發(fā)者感受不到它的升級(jí)。但是，這對(duì)框架二次開發(fā)者并不可能完全透明，因?yàn)槎伍_發(fā)經(jīng)常會(huì)用到其Low-Level的API，比如今天的主角PathPattern就算其中之一，所以說我們要與時(shí)俱進(jìn)呀o(╥﹏╥)o!

Spring 5雖然新增了(更好的)PathPattern，但它不能完全替代掉AntPathMatcher，因?yàn)榍罢邔閣eb設(shè)計(jì)，所以在web領(lǐng)域是可完全替代掉AntPathMatcher的。但在非web領(lǐng)域內(nèi)，AntPathMatcher依舊不可替代。

本文轉(zhuǎn)載自微信公眾號(hào)「 BAT的烏托邦」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系 BAT的烏托邦公眾號(hào)。