路径匹配
Servlet API 将完整的请求路径作为 requestURI 暴露出来，并进一步将其细分为 contextPath、servletPath 和 pathInfo，这些值的取值取决于 Servlet 的映射方式。基于这些输入，Spring MVC 需要确定用于映射处理器的查找路径，在该路径中应排除 contextPath 以及任何适用的 servletMapping 前缀。
servletPath 和 pathInfo 会被解码，这就导致无法直接将它们与完整的 requestURI 进行比较以得出 lookupPath，因此有必要对 requestURI 本身进行解码。然而，这也会引入新的问题，因为路径可能包含诸如 / 或 ";" 等编码后的特殊字符，这些字符在解码后可能会改变路径的结构，进而可能导致安全问题。此外，Servlet 容器可能会以不同的程度对 servletPath 进行规范化处理，这使得进一步使用 startsWith 方法与 requestURI 进行比较变得不可能。
这就是为什么最好避免依赖带有前缀的servletPath映射类型所提供的servletPath。如果DispatcherServlet被映射为默认Servlet，使用"/"作为路径，或者没有前缀而使用"*"，并且Servlet容器是4.0及以上版本，那么Spring MVC就能够检测到这种Servlet映射类型，从而完全避免使用servletPath和pathInfo。在3.1版本的Servlet容器上，假设定相同的Servlet映射类型，可以通过在MVC配置中通过路径匹配为UrlPathHelper设置alwaysUseFullPath=true来实现相同的效果。
幸运的是，默认的Servlet映射“/”是一个不错的选择。然而，仍然存在一个问题，即需要解码requestURI才能将其与控制器映射进行比较。这同样是不理想的，因为存在解码可能改变路径结构的保留字符的风险。如果不需要这些字符，那么可以像Spring Security的HTTP防火墙那样拒绝它们；或者可以配置UrlPathHelper为urlDecode=false，但此时控制器映射需要与编码后的路径匹配，而这并不总是能够很好地工作。此外，有时DispatcherServlet需要与其他Servlet共享URL空间，可能需要通过前缀来进行映射。
当使用PathPatternParser和解析后的模式时，上述问题就会得到解决，这可以作为使用AntPathMatcher进行字符串路径匹配的替代方案。PathPatternParser从Spring MVC 5.3版本开始就可以使用，而从6.0版本起则默认启用。与AntPathMatcher不同，后者要么需要解码路径，要么需要编码控制器映射，而PathPatternParser则是针对被称为RequestPath的路径的解析表示进行匹配，一次匹配一个路径段。这样一来，就可以单独解码和清理每个路径段的值，而不会冒着改变路径结构的风险。只要使用了Servlet路径映射，并且前缀保持简单（即不含编码字符），解析后的PathPattern还支持使用servletPath前缀映射。有关模式语法的详细信息和比较，请参阅模式比较。