1. Spring Security 的配置文件时代记得我第一次用 Spring Security 是在五年前的一个内部管理系统项目上。当时为了快速上线直接在 application.yml 里写死了用户名密码就像这样spring: security: user: name: admin password: 123456 roles: ADMIN这种配置方式简单粗暴到什么程度呢你甚至不需要写任何 Java 代码只要引入了 spring-boot-starter-security 依赖系统就会自动弹出一个默认登录页。我当年就是被这种开箱即用的特性惊艳到了但很快就在实际项目中碰了钉子。内存用户的局限性在真实场景中会立刻暴露密码明文存储连 base64 编码都没有用户信息硬编码在配置文件里每次修改用户都要重启服务角色权限是写死的字符串更麻烦的是 URL 权限控制。比如你想让/api/public允许匿名访问/api/admin需要管理员权限在纯配置文件中几乎无法实现。这时候就得请出 WebSecurityConfigurerAdapter 这个老朋友了。2. 配置类真正的生产级方案2.1 基础配置类搭建先看一个典型的 SecurityConfig 骨架Configuration EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers(/public/**).permitAll() .antMatchers(/admin/**).hasRole(ADMIN) .anyRequest().authenticated() .and() .formLogin(); } }这个配置类做了三件大事开放/public路径的匿名访问限制/admin路径仅限 ADMIN 角色访问其他所有请求都需要登录关键进化点在于权限规则可编程化能用 if-else 逻辑支持方法级注解控制后面会讲可以集成数据库用户体系2.2 用户认证的三种姿势配置类最大的优势是能灵活定义用户来源。我整理过三种常见方案方案适用场景示例代码片段内存用户测试环境auth.inMemoryAuthentication()JDBC 认证中小型生产系统auth.jdbcAuthentication()自定义 UserDetails复杂权限系统auth.userDetailsService()最推荐的是第三种自定义实现。比如对接公司 LDAP 或自定义权限表时Override protected void configure(AuthenticationManagerBuilder auth) throws Exception { auth.userDetailsService(myUserService) .passwordEncoder(bCryptPasswordEncoder()); }3. 方法级权限控制实战URL 级别的控制还不够精细试试方法注解PreAuthorize(hasRole(ADMIN) or #userId authentication.name) public User getUserProfile(String userId) { // 仅管理员或用户本人可访问 }注解三剑客的适用场景PreAuthorize方法执行前校验最常用PostAuthorize方法执行后校验较少用Secured简单角色校验Spring 原生注解特别注意要启用这些注解必须在配置类加上EnableGlobalMethodSecurity( prePostEnabled true, // 开启Pre/Post注解 securedEnabled true // 开启Secured )4. 现代 Spring Security 的最佳实践最近两年 Spring Security 又有新变化。比如 WebSecurityConfigurerAdapter 已经被标记为过时推荐使用组件式配置Bean SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { return http .authorizeHttpRequests(auth - auth .requestMatchers(/public/**).permitAll() .anyRequest().authenticated() ) .formLogin(withDefaults()) .build(); }新旧版本对比表特性旧版 (5.7)新版 (6.0)配置方式继承抽象类组件式 Bean请求匹配antMatchersrequestMatchers密码编码器需要显式配置强制要求加密CSRF 防护默认开启默认关闭升级时最容易踩的坑是密码编码器。新版强制要求必须配置推荐使用Bean PasswordEncoder passwordEncoder() { return PasswordEncoderFactories.createDelegatingPasswordEncoder(); }在实际项目中我通常会额外配置这些安全防护会话固定保护session fixation点击劫持防护X-Frame-Options内容安全策略CSP 头部安全请求头HSTS 等这些配置现在都可以通过 lambda DSL 流畅地表达http.securityContext(context - context .requireExplicitSave(false)) .headers(headers - headers .frameOptions().sameOrigin() .contentSecurityPolicy(csp - csp .policyDirectives(default-src self))) .csrf(csrf - csrf.ignoringRequestMatchers(/api/**));从配置文件到配置类再到现在的组件式配置Spring Security 的演进始终围绕着两个核心目标安全性的强化和开发体验的优化。每次升级都意味着更少的样板代码和更精确的安全控制这才是框架设计的艺术。