SpringBoot集成Spring Security实战：从配置到排错全解析

SpringBoot集成Spring Security实战：从配置到排错全解析

发布时间：2026/10/16 15:33:26
SpringBoot集成Spring Security实战：从配置到排错全解析 1. 项目概述为什么在SpringBoot里绕不开Security“SpringBoot下使用Security”——这短短八个字是过去五年里我见过最多次出现在简历项目栏、技术面试开场白、以及凌晨两点的Stack Overflow搜索框里的组合。它不是某个炫技的新框架而是一道几乎无法绕开的工程门槛当你用SpringBoot快速搭起一个用户能注册、登录、查看个人中心的系统时Security就是那个默默站在你代码背后、替你挡住90%基础安全风险的守门人。它不声张但一旦缺位轻则被爬虫扫光数据库重则用户密码明文泄露、接口被恶意刷单、后台管理页变成公开游乐场。我带过的几个团队里有新人用SpringBoot写了三个月业务逻辑直到上线前一周才第一次听说Security结果三天内紧急补上配置又花两周时间排查CSRF误拦截、权限注解失效、密码加密方式不兼容这些“本该一开始就定死”的问题。所以这篇内容不是教你怎么复制粘贴几行配置而是带你回到真实开发现场Security到底在解决什么为什么SpringBoot要为它专门设计自动装配机制哪些配置项看似可选实则动一发而牵全身它和你写的Controller、Service之间到底存在怎样的隐式契约如果你正卡在“登录成功却跳转不到首页”“明明配置了角色却提示403”“密码加密后前端传过来的永远校验失败”这类问题上那说明你已经踩进了Security最典型的认知断层区——它表面是过滤器链配置底层其实是整个应用的请求生命周期重写。接下来我会用一个真实压测环境下的案例切入某次灰度发布时Security的默认会话超时策略导致大量用户在支付中途被强制登出我们如何通过源码级调试定位到SessionRegistry的并发计数缺陷并用一行Bean覆盖修复。这不是理论推演而是把Security当成一个需要你亲手拆解、调试、甚至打补丁的活体组件来对待。2. 核心设计思路与方案选型解析2.1 Security不是插件而是应用骨架的重铸很多初学者把Spring Security当成一个“加个依赖就能用”的安全插件这是最危险的认知偏差。实际上当你引入spring-boot-starter-securitySpringBoot自动装配的远不止几个过滤器。它会悄然接管整个HTTP请求处理流程从Tomcat接收到原始Socket数据到最终你的RestController方法返回JSON中间至少经过12个Security专属过滤器FilterChainProxy管理的SecurityFilterChain每个过滤器都可能中断、重定向、或修改请求/响应。比如UsernamePasswordAuthenticationFilter会在/login路径上截获表单提交解析username和password参数调用AuthenticationManager进行认证而ExceptionTranslationFilter则像一个兜底捕手在任何过滤器抛出AccessDeniedException或AuthenticationException时统一跳转到登录页或返回401。这种深度侵入性意味着Security的配置不是“锦上添花”而是定义应用安全边界的基石。我见过最典型的反模式是开发者在Controller里手动校验SecurityContextHolder.getContext().getAuthentication()以为这样就实现了权限控制。实则大错特错——这相当于让保安在大门外巡逻时还要求每个进门的人自己掏出身份证给前台核对。正确姿势是让Security在请求进入Controller之前就完成所有鉴权Controller只专注业务逻辑。因此方案选型的第一原则是拒绝手动安全校验拥抱声明式安全。这意味着你要熟练使用PreAuthorize(hasRole(ADMIN))、PostFilter(filterObject.owner authentication.name)这类注解而不是在Service里写if (!hasPermission()) throw new AccessDeniedException()。后者不仅耦合度高更致命的是它绕过了Security的审计日志、失败计数、账户锁定等内置防护机制。2.2 为什么选择基于内存的InMemoryUserDetailsManager做初期验证在项目启动阶段我强烈建议先用InMemoryUserDetailsManager而非直接对接数据库。这不是偷懒而是为了隔离验证环节。想象一下你刚写完登录接口却遇到“Bad credentials”错误。此时如果后端直连MySQL你需要同时排查5个层面前端密码是否被JS加密、HTTP请求头Content-Type是否正确、SpringBoot是否启用了EnableWebSecurity、UserDetailsService实现类是否被Spring扫描到、数据库密码字段是否按BCrypt格式存储。而换成内存用户你只需确认三点UserDetails对象的password字段是否以{bcrypt}$2a$10$...开头、username是否完全匹配注意大小写、enabled属性是否为true。我曾帮一个团队定位过一个持续两天的登录失败问题最终发现是MySQL的utf8mb4字符集导致密码哈希值末尾多了一个不可见空格而内存方案能瞬间排除数据库干扰。当然内存方案仅限于开发验证。正式环境必须切换到JdbcUserDetailsManager或自定义UserDetailsService这时关键在于密码编码器的全局一致性。Spring Security 5.0之后强制要求显式声明PasswordEncoder且必须与数据库中存储的哈希格式严格匹配。常见陷阱是开发时用NoOpPasswordEncoder明文存储上线后换成BCryptPasswordEncoder结果所有老用户无法登录。解决方案是在SecurityConfig中定义Bean PasswordEncoder passwordEncoder()并确保DAO层插入新用户时调用passwordEncoder.encode(rawPassword)再存库。这里有个硬性经验永远不要在SQL脚本里硬编码密码哈希值而要在应用启动时通过CommandLineRunner批量初始化测试账号。2.3 过滤器链顺序为什么CorsConfigurationSource必须在SecurityFilterChain之前Spring Security的过滤器链顺序不是随意排列的而是遵循严格的“先跨域、再认证、后授权”逻辑。CorsConfigurationSource负责处理浏览器预检请求OPTIONS它必须在任何认证过滤器之前执行。否则当前端发起带Authorization头的跨域请求时浏览器会先发一个无头的OPTIONS请求而Security的BasicAuthenticationFilter会因缺少凭证直接返回401导致预检失败后续真正的GET/POST请求根本发不出去。这个问题在VueSpringBoot联调时高频出现。解决方案是在SecurityConfig中显式配置CORSBean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .cors(cors - cors.configurationSource(corsConfigurationSource())) // 必须第一行 .csrf(csrf - csrf.disable()) // 开发期可禁用生产必须配置 .authorizeHttpRequests(authz - authz .requestMatchers(/public/**).permitAll() .requestMatchers(/admin/**).hasRole(ADMIN) .anyRequest().authenticated() ); return http.build(); } Bean public CorsConfigurationSource corsConfigurationSource() { CorsConfiguration configuration new CorsConfiguration(); configuration.setAllowedOrigins(Arrays.asList(http://localhost:8080, https://myapp.com)); configuration.setAllowedMethods(Arrays.asList(GET, POST, PUT, DELETE, OPTIONS)); configuration.setAllowCredentials(true); configuration.addExposedHeader(X-Total-Count); // 暴露分页总数头 UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, configuration); return source; }注意cors.configurationSource(...)必须是http配置块的第一行这是Spring Security 6.x的强制约定。另外setAllowCredentials(true)时allowedOrigins不能为*必须指定具体域名否则浏览器会拒绝携带Cookie的请求——这直接导致登录态无法维持。3. 核心细节解析与实操要点3.1UserDetails接口的四个必重写方法不只是签名游戏UserDetails是Security用户模型的核心契约但很多人只关注getUsername()和getPassword()却忽略其余三个方法对系统稳定性的影响。isEnabled()控制账户启用状态但它的真正威力在于与LockoutFailureHandler联动当连续登录失败5次JdbcUserDetailsManager会将数据库enabled字段设为false此时isEnabled()返回falseSecurity自动拒绝后续所有认证请求无需额外代码。isAccountNonExpired()和isCredentialsNonExpired()则分别对应账户有效期和密码有效期。我在某金融项目中遇到过线上事故运营人员误将测试账号的accountNonExpired设为false导致所有用户无法登录因为Security在认证成功后会二次校验这两个方法任一返回false即抛出DisabledException。因此数据库设计时必须包含account_non_expired、credentials_non_expired、account_locked、enabled四个布尔字段并在UserDetails实现类中严格映射。更关键的是getAuthorities()返回的Collection? extends GrantedAuthority不能是null或空集合否则FilterSecurityInterceptor会因无法解析权限而抛出AccessDeniedException。我推荐的实现是Override public Collection? extends GrantedAuthority getAuthorities() { // 避免返回null空权限也返回空集合 return Optional.ofNullable(authorities) .map(ArrayList::new) .orElseGet(ArrayList::new); }3.2 密码编码器的版本陷阱BCrypt的strength参数为何必须是10BCryptPasswordEncoder的strength参数默认10代表哈希计算的轮数值越大越安全但越耗CPU。但很多人不知道这个参数必须与数据库中已存哈希值的轮数严格一致。BCrypt哈希字符串形如$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy其中$10$就是轮数值。如果数据库里存的是$2a$12$...strength12而代码中用new BCryptPasswordEncoder(10)则matches()方法永远返回false。更隐蔽的问题是$2a$、$2b$、$2y$前缀的兼容性。$2a$是旧版$2y$是修复了特定漏洞的版本Spring Security 5.7默认使用$2y$。如果你的遗留系统用$2a$生成密码新代码必须显式指定Bean public PasswordEncoder passwordEncoder() { // 兼容旧版$2a$前缀 return new BCryptPasswordEncoder(10, new SecureRandom()); }而生产环境推荐使用DelegatingPasswordEncoder它能根据哈希前缀自动选择解码器Bean public PasswordEncoder passwordEncoder() { MapString, PasswordEncoder encoders new HashMap(); encoders.put(bcrypt, new BCryptPasswordEncoder(12)); encoders.put(pbkdf2, new Pbkdf2PasswordEncoder()); return new DelegatingPasswordEncoder(bcrypt, encoders); }此时数据库密码需以{bcrypt}$2a$...或{pbkdf2}$...开头Security会自动识别前缀并委托对应编码器处理。3.3 CSRF防护的现代取舍为什么REST API通常禁用而管理后台必须启用CSRF跨站请求伪造攻击的本质是利用用户已登录的Cookie在不知情下提交恶意请求。对于传统表单提交的Web应用如Thymeleaf模板CSRF Token是刚需表单中嵌入input typehidden name_csrf value...Security在CsrfFilter中校验该Token。但对纯REST API如Vue调用/api/userCSRF防护反而成为负担。原因有三第一前端通常用JWT或Bearer Token认证不依赖Cookie攻击者无法窃取Token第二每次请求需携带CSRF Token增加前端复杂度第三移动端App无法像浏览器一样自动携带Cookie。因此我的实践准则是前后端分离的API服务禁用CSRF基于Session的传统Web应用必须启用并正确传递Token。禁用方法很简单http.csrf(csrf - csrf.disable())但禁用不等于放弃防护。此时应强化其他层1所有敏感操作删除、支付必须用POST/PUT/DELETE禁用GET2关键接口添加二次验证短信/邮箱验证码3使用SameSiteStrictCookie属性防止跨站携带。而对于管理后台CSRF Token必须贯穿全流程。我曾在一个后台系统中发现前端用Axios全局拦截器自动注入X-CSRF-TOKEN头但忘记在login接口成功后更新Token导致后续所有请求因Token过期被拒。解决方案是在登录成功后的AuthenticationSuccessHandler中将新Token写入响应头public class CustomAuthSuccessHandler implements AuthenticationSuccessHandler { Override public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response, Authentication successfulAuthentication) throws IOException { // 生成新CSRF Token并写入响应头 CsrfToken csrfToken (CsrfToken) request.getAttribute(_csrf); response.setHeader(X-CSRF-TOKEN, csrfToken.getToken()); response.sendRedirect(/admin/dashboard); } }4. 实操过程与核心环节实现4.1 从零搭建一个可运行的Security配置逐行解读关键配置我们以一个标准的前后端分离项目为例实现登录、权限控制、登出全流程。首先添加依赖pom.xmldependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-jpa/artifactId /dependency dependency groupIdcom.h2database/groupId artifactIdh2/artifactId scoperuntime/scope /dependency注意spring-boot-starter-security必须显式声明SpringBoot 3.x不再默认启用Security。接下来创建核心配置类Configuration EnableWebSecurity public class SecurityConfig { // 1. 定义密码编码器必须 Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(12); } // 2. 定义用户详情服务必须 Bean public UserDetailsService userDetailsService(JdbcTemplate jdbcTemplate) { String usersByUsernameQuery select username, password, enabled from users where username ?; String authsByUserQuery select username, authority from authorities where username ?; return new JdbcUserDetailsManager(jdbcTemplate, usersByUsernameQuery, authsByUserQuery); } // 3. 定义安全过滤器链必须 Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http // CORS配置必须在第一位 .cors(cors - cors.configurationSource(corsConfigurationSource())) // 禁用CSRFREST API场景 .csrf(csrf - csrf.disable()) // 会话管理 .sessionManagement(session - session .sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED) .invalidSessionUrl(/login?invalid-sessiontrue) .maximumSessions(1) .maxSessionsPreventsLogin(false) .expiredSessionStrategy(new CustomExpiredSessionStrategy()) ) // 异常处理 .exceptionHandling(exceptions - exceptions .authenticationEntryPoint(new CustomAuthEntryPoint()) .accessDeniedHandler(new CustomAccessDeniedHandler()) ) // 请求授权规则 .authorizeHttpRequests(authz - authz .requestMatchers(/login, /register, /public/**).permitAll() .requestMatchers(/admin/**).hasRole(ADMIN) .requestMatchers(/user/**).hasAnyRole(USER, ADMIN) .anyRequest().authenticated() ) // 表单登录配置 .formLogin(form - form .loginPage(/login) .loginProcessingUrl(/perform_login) .defaultSuccessUrl(/dashboard, true) .failureUrl(/login?errortrue) .usernameParameter(username) .passwordParameter(password) .successHandler(new CustomAuthSuccessHandler()) .failureHandler(new CustomAuthFailureHandler()) ) // 登出配置 .logout(logout - logout .logoutUrl(/perform_logout) .logoutSuccessUrl(/login?logouttrue) .invalidateHttpSession(true) .clearAuthentication(true) .deleteCookies(JSESSIONID) ); return http.build(); } // 4. CORS配置源必须 Bean public CorsConfigurationSource corsConfigurationSource() { CorsConfiguration configuration new CorsConfiguration(); configuration.setAllowedOrigins(Arrays.asList(http://localhost:3000)); configuration.setAllowedMethods(Arrays.asList(GET, POST, PUT, DELETE, OPTIONS)); configuration.setAllowCredentials(true); configuration.addExposedHeader(X-Total-Count); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, configuration); return source; } }关键点解析EnableWebSecurity是Spring Security 6.x的必需注解替代了旧版的EnableWebMvcSecurity。sessionManagement()中maximumSessions(1)限制单用户只能一处登录maxSessionsPreventsLogin(false)表示新登录时踢掉旧会话而非拒绝新登录。formLogin().loginProcessingUrl(/perform_login)指定了表单提交的目标URL必须与HTML表单的action属性一致。logout().deleteCookies(JSESSIONID)显式删除会话Cookie避免登出后Cookie仍有效。4.2 数据库初始化H2内存库的完整建表与测试数据为快速验证我们使用H2内存数据库。在application.yml中配置spring: h2: console: enabled: true path: /h2-console datasource: url: jdbc:h2:mem:testdb;DB_CLOSE_DELAY-1;DB_CLOSE_ON_EXITFALSE driver-class-name: org.h2.Driver username: sa password: jpa: database-platform: org.hibernate.dialect.H2Dialect hibernate: ddl-auto: create-drop创建初始化SQLsrc/main/resources/data.sql-- 创建用户表 CREATE TABLE users ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, enabled BOOLEAN DEFAULT TRUE, account_non_expired BOOLEAN DEFAULT TRUE, credentials_non_expired BOOLEAN DEFAULT TRUE, account_locked BOOLEAN DEFAULT FALSE ); -- 创建权限表 CREATE TABLE authorities ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL, authority VARCHAR(50) NOT NULL, CONSTRAINT fk_authorities_users FOREIGN KEY (username) REFERENCES users(username) ); -- 插入测试用户密码为password经BCrypt编码 INSERT INTO users (username, password, enabled) VALUES (admin, {bcrypt}$2a$12$KQVfBvYxZzRwTtUuIiOoPpNnMmLlKkJjHhGgFfDdSsAaZzXx, TRUE), (user, {bcrypt}$2a$12$KQVfBvYxZzRwTtUuIiOoPpNnMmLlKkJjHhGgFfDdSsAaZzXx, TRUE); -- 插入权限 INSERT INTO authorities (username, authority) VALUES (admin, ROLE_ADMIN), (admin, ROLE_USER), (user, ROLE_USER);注意密码哈希值需用BCryptPasswordEncoder.encode(password)生成不能手写。可在PostConstruct方法中动态生成Component public class DataInitializer { Autowired private JdbcTemplate jdbcTemplate; Autowired private PasswordEncoder passwordEncoder; PostConstruct public void init() { String encodedPassword passwordEncoder.encode(password); jdbcTemplate.update( INSERT INTO users (username, password, enabled) VALUES (?, ?, ?), admin, encodedPassword, true ); jdbcTemplate.update( INSERT INTO authorities (username, authority) VALUES (?, ?), admin, ROLE_ADMIN ); } }4.3 前端联调关键如何让Vue Axios正确携带认证信息前后端分离下登录成功后前端必须持久化认证凭证。Spring Security默认使用JSESSIONIDCookie因此前端需配置Axios全局设置// axios.js import axios from axios // 启用withCredentials使请求携带Cookie axios.defaults.withCredentials true // 设置基础URL axios.defaults.baseURL http://localhost:8080 // 请求拦截器添加CSRF Token如果启用 axios.interceptors.request.use(config { const csrfToken localStorage.getItem(X-CSRF-TOKEN) if (csrfToken config.method.toUpperCase() ! GET) { config.headers[X-CSRF-TOKEN] csrfToken } return config }) // 响应拦截器处理401/403 axios.interceptors.response.use( response response, error { if (error.response?.status 401) { window.location.href /login } return Promise.reject(error) } ) export default axios关键点withCredentials true是必须的否则浏览器不会发送Cookie。localStorage.getItem(X-CSRF-TOKEN)需在登录成功后由后端写入见4.1节CustomAuthSuccessHandler。对于GET请求通常不需CSRF Token故拦截器中做了方法判断。登录接口调用示例// login.vue methods: { async handleLogin() { try { const res await axios.post(/perform_login, { username: this.username, password: this.password }) // 登录成功跳转首页 this.$router.push(/dashboard) } catch (error) { this.errorMessage 用户名或密码错误 } } }注意/perform_login是Security配置的loginProcessingUrl不是自定义Controller。Spring Security会自动处理此路径。5. 常见问题与排查技巧实录5.1 问题速查表高频故障现象与根因定位现象可能根因排查步骤解决方案登录成功后跳转到/login页面循环defaultSuccessUrl未设alwaysUsetrue或/dashboard被permitAll()放行1. 检查SecurityConfig中defaultSuccessUrl(/dashboard, true)2. 查看/dashboard是否在permitAll()列表中移除/dashboard的permitAll()确保其需要authenticated()访问/admin/**返回403 Forbidden用户无ROLE_ADMIN权限或hasRole(ADMIN)未匹配数据库中的ROLE_ADMIN1. 查询数据库authorities表确认用户有ROLE_ADMIN记录2. 检查getAuthorities()返回的GrantedAuthority是否含ROLE_ADMIN确保数据库权限值为ROLE_ADMIN必须带ROLE_前缀或改用hasAuthority(ADMIN)登录后无法访问任何接口全部401前端未发送JSESSIONIDCookie或withCredentialsfalse1. 浏览器开发者工具Network标签检查请求Headers是否有Cookie: JSESSIONIDxxx2. 检查Axios配置withCredentialstrue在Axios全局配置中设置withCredentials true并确保后端CORS允许凭据Bad Credentials错误但密码确认正确密码编码器不匹配或数据库密码字段长度不足1. 检查BCryptPasswordEncoder的strength是否与哈希值前缀一致2. 查看数据库password字段类型是否为VARCHAR(100)BCrypt哈希约60字符将密码字段改为VARCHAR(100)确保编码器strength与哈希前缀一致登出后仍能访问受保护接口logout()配置未invalidateHttpSession(true)或前端未清除Cookie1. 检查SecurityConfig中logout().invalidateHttpSession(true)2. 浏览器Application标签确认JSESSIONIDCookie已被删除显式配置invalidateHttpSession(true)和deleteCookies(JSESSIONID)5.2 深度调试技巧如何用断点精准定位Security过滤器链问题当常规排查无效时需深入Security源码。我的标准调试流程如下第一步开启Security调试日志在application.yml中添加logging: level: org.springframework.security: DEBUG org.springframework.web: DEBUG启动后控制台会输出详细的过滤器链执行日志例如Securing GET /login Will not secure GET /login Securing POST /perform_login Trying to match using Ant [pattern/login] Checking match of request : /perform_login; against /login第二步在关键过滤器打条件断点在IDE中打开UsernamePasswordAuthenticationFilter在其attemptAuthentication()方法首行打断点。条件设置为request.getRequestURL().toString().contains(perform_login)确保只在登录请求时触发。第三步跟踪AuthenticationManager执行流当断点停住F7步入this.getAuthenticationManager().authenticate(authentication)你会进入ProviderManager.authenticate()。此处可观察AuthenticationProvider列表确认DaoAuthenticationProvider是否在首位。若UserDetailsService未正确注入此处会抛出ProviderNotFoundException。第四步检查SecurityContext是否持久化在任意Controller方法中添加断点并执行Authentication auth SecurityContextHolder.getContext().getAuthentication(); System.out.println(Current auth: auth);若返回null说明Security上下文未正确绑定到当前线程。常见原因是异步方法Async中未手动传播上下文需配置SecurityContextPropagation。5.3 生产环境避坑清单那些文档不会写的血泪教训会话超时时间必须前后端一致Spring Boot的server.servlet.session.timeout180030分钟必须与前端Token刷新逻辑同步。我曾遇到前端每25分钟刷新一次Token但后端Session 30分钟过期导致第28分钟的请求因Session失效被重定向到登录页。解决方案是后端Session超时设为45分钟前端每35分钟刷新。PreAuthorize注解在Service层失效默认情况下EnableGlobalMethodSecurity旧版或EnableMethodSecurity新版只对Controller生效。若要在Service层使用必须在配置类上添加proxyTargetClass trueEnableMethodSecurity(proxyTargetClass true)HikariCP连接池与Security的UserDetailsService冲突当JdbcUserDetailsManager查询用户时若数据库连接池已满会导致登录请求阻塞。解决方案是为Security专用数据源配置独立连接池Bean Primary public DataSource securityDataSource() { HikariDataSource ds new HikariDataSource(); ds.setJdbcUrl(jdbc:h2:mem:testdb); ds.setUsername(sa); ds.setMaximumPoolSize(5); // 限制为5避免抢占主业务连接 return ds; }Order注解的隐形陷阱当项目中有多个SecurityFilterChainBean如API和管理后台分离配置必须用Order明确优先级。Order(SecurityProperties.BASIC_AUTH_ORDER - 10)是常用值但更安全的做法是用常量Bean Order(1) public SecurityFilterChain apiFilterChain(HttpSecurity http) { ... } Bean Order(2) public SecurityFilterChain adminFilterChain(HttpSecurity http) { ... }最后分享一个小技巧在SecurityConfig中添加一个Bean用于打印所有启用的过滤器方便快速确认链结构Bean public FilterRegistrationBeanFilter filterRegistrationBean() { FilterRegistrationBeanFilter registrationBean new FilterRegistrationBean(); registrationBean.setFilter(new OncePerRequestFilter() { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { System.out.println(Active filters: Arrays.toString( ((FilterChainProxy) request.getAttribute(org.springframework.security.web.FilterChainProxy)).getFilterChains().toArray())); filterChain.doFilter(request, response); } }); registrationBean.setOrder(Ordered.LOWEST_PRECEDENCE); return registrationBean; }这个Bean会在每次请求时打印当前激活的过滤器链是排查“为什么这个请求没进Security”的终极利器。