你遇到的问题核心在于Spring Security的规则匹配顺序以及CSRF保护对特定请求方法的影响，下面一步步给你拆解：

问题1：规则匹配顺序的优先级错误 #

你的配置里，.antMatchers("/**").authenticated() 放在了匿名访问规则之后，这会导致所有请求（包括你想放行的/actuator/**和/v1/foo/link）都被匹配到兜底的认证规则上。Spring Security的规则是从上到下匹配，一旦匹配到就停止后续规则判断，所以必须把更具体的放行规则放在前面，宽泛的兜底规则放在最后。

问题2：CSRF保护的隐性限制 #

当你禁用CSRF后请求恢复正常，说明你访问放行路径时用了POST/DELETE/PUT等非GET类请求方法。Spring Security默认会对这些方法启用CSRF校验，哪怕你配置了permitAll，如果没有正确携带CSRF令牌，依然会返回403。全局禁用CSRF并不安全，我们可以针对性处理。

修复后的完整配置 #

@Configuration 
@EnableWebSecurity 
public class SecurityConfig extends WebSecurityConfigurerAdapter { 
    @Override 
    protected void configure(HttpSecurity http) throws Exception { 
        http
            // 针对性忽略放行路径的CSRF校验（仅当需要支持非GET请求时配置）
            .csrf(csrf -> csrf
                .ignoringAntMatchers("/actuator/**","/v1/foo/link")
            )
            .authorizeRequests()
                // 先配置具体的放行规则
                .antMatchers("/actuator/**","/v1/foo/link").permitAll()
                // 最后配置兜底的认证规则
                .anyRequest().authenticated()
            .and()
            .oauth2ResourceServer()
                .jwt(withDefaults()); 
    } 
}

方案说明 #

1. 调整规则顺序：把permitAll的具体路径放在.anyRequest().authenticated()之前，确保这些路径先被匹配到，直接跳过认证流程。
2. 精准关闭CSRF：如果你的放行接口需要接收非GET请求，不要全局禁用CSRF，只忽略这些特定路径的校验即可——既保证其他接口的安全性，又解决了403问题。
3. 特殊情况：如果你的放行路径只需要支持GET请求，其实无需修改CSRF配置，仅调整规则顺序就能解决问题（Spring Security默认不对GET请求做CSRF校验）。

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