Spring Security 5→6迁移：requestMatchers与securityMatchers区别及代码等价性问询

一、旧requestMatchers与新securityMatchers的核心区别 #

• 作用范围差异
  • 旧版requestMatchers（嵌套在authorizeHttpRequests下）：仅限定授权规则的适用请求范围，整个Security Filter Chain仍会处理所有请求，只是对匹配的请求应用授权逻辑。
  • 新版securityMatcher：直接限定整个Filter Chain的处理范围，只有匹配的请求才会进入当前FilterChain，不匹配的请求会直接跳过整个安全链，能减少不必要的安全处理开销。
• 配置层级差异
  • 旧版requestMatchers是authorizeHttpRequests的子配置，属于授权规则的一部分，无法控制FilterChain是否启动。
  • 新版securityMatcher是HttpSecurity的顶层配置，是FilterChain的入口判断条件，优先级高于所有授权规则。
• 多FilterChain场景差异
  • 旧版用requestMatchers配置多FilterChain时，可能出现多个链同时处理同一请求的情况，需依赖order属性指定优先级。
  • 新版securityMatcher可精准划分每个FilterChain的处理请求集，不同链的处理范围互不重叠，避免规则冲突。

二、代码等价性判断 #

先明确三段代码的实际行为：

// 代码1：Spring Security 5写法
//http.authorizeHttpRequests((authz) -> authz.anyRequest());
// 代码2：Spring Security 6写法
//http.securityMatcher().authorizeHttpRequests((authz) -> authz.anyRequest());
// 代码3：当前使用的代码
http.requestMatchers().anyRequest();

这三段代码并不等价，具体原因：

1. 代码1和代码2都完成了两个动作：一是指定了匹配范围（所有请求），二是为匹配的请求配置了授权规则（虽然这里仅声明了匹配所有请求，未指定具体授权策略如permitAll/authenticated）。
2. 代码3仅完成了指定FilterChain的匹配范围为所有请求，但完全没有配置任何授权规则，请求进入FilterChain后不会受到任何授权校验，和前两段代码的完整逻辑差距很大。

如果要让代码3达到类似代码1/2的逻辑，需要补充授权规则配置，示例：

http.requestMatchers().anyRequest()
    .authorizeHttpRequests(authz -> authz.anyRequest().authenticated());

内容的提问来源于stack exchange，提问作者Andreas