路径匹配
Servlet API 将完整的请求路径公开为requestURI并进一步细分 到contextPath,servletPath和pathInfo其值根据如何变化Servlet 的映射方式。从这些输入中，Spring MVC 需要确定用于映射处理程序的查找路径，这应该排除contextPath和任何servletMapping前缀（如果适用）。
这servletPath和pathInfo被解码，这使得它们无法比较直接到完整的requestURI为了派生 lookupPath，这使得有必要解码requestURI. 然而，这带来了它自己的问题，因为path 可能包含编码的保留字符，例如 或 反过来可以在解码后改变路径的结构，这也可能导致安全性 问题。 此外，Servlet 容器可以规范化"/"";"servletPath到不同的程度，这使得它进一步无法执行startsWith比较 这requestURI.
这就是为什么最好避免依赖servletPath它附带了基于前缀servletPath映射类型。如果DispatcherServlet映射为default Servlet 带或不带前缀 with 和 Servlet容器为 4.0+，则 Spring MVC 能够检测 Servlet 映射类型并避免使用"/""/*"servletPath和pathInfo完全。 在 3.1 Servlet 容器上，假设相同的 Servlet 映射类型，可以通过提供 一个UrlPathHelper跟alwaysUseFullPath=true通过路径匹配MVC 配置。
幸运的是，默认的 Servlet 映射是一个不错的选择。但是，仍然存在一个问题，即"/"requestURI需要解码才能与控制器映射进行比较。这又是不可取的，因为有可能解码改变路径结构的保留字符。如果不需要此类字符，那么您可以拒绝它们（如 Spring Security HTTP 防火墙），或者您可以配置UrlPathHelper跟urlDecode=false但控制器映射需要与编码路径匹配，这可能并不总是正常工作。此外，有时DispatcherServlet需要与另一个 Servlet 共享 URL 空间，并且可能需要按前缀映射。
上述问题在使用PathPatternParser和解析的模式，作为字符串路径匹配的替代方案AntPathMatcher. 这PathPatternParser已从 5.3 版开始可在 Spring MVC 中使用，并且默认从6.0 版启用。 与AntPathMatcher需要解码查找路径或控制器映射编码，解析PathPattern与解析后的表示形式匹配调用的路径RequestPath，一次一个路径段。这允许解码和单独清理路径段值，而不会有改变结构的风险路径的。 解析PathPattern还支持使用servletPath前缀映射只要使用 Servlet 路径映射并且前缀保持简单，即它没有编码字符。有关模式语法的详细信息和比较，请参阅模式比较。