一、 背景与痛点
在传统的 Spring Security 开发中（尤其是单体大应用），我们往往会在一个主配置类（如SecurityConfig）里写死所有的 URL 权限规则：
// 传统写法：随着业务增长，这个方法会变成几百行的“面条代码”http.authorizeHttpRequests().requestMatchers("/admin/**").hasRole("ADMIN").requestMatchers("/order/**").hasRole("USER").requestMatchers("/pay/**").permitAll()// ... 无休止的追加 ...痛点：
- 严重耦合：基础架构层必须感知所有业务模块的 URL 规则。
- 维护困难：多人开发时，大家都在修改同一个文件，代码冲突不断。
- 扩展性差：新增一个业务模块，必须去改主工程的代码。
二、 核心架构设计
为了解决上述问题，我们引入了“插拔式”的设计模式。核心由三个部分组成：
- 调度中心：主配置类（只负责调度，不负责具体规则）。
- 标准协议：
AuthorizeRequestsCustomizer抽象类（定义怎么配）。 - 业务实现：各模块的 Customizer（具体配什么）。
1. 调度中心：主 SecurityFilterChain
在主配置类（如YudaoWebSecurityConfigurerAdapter）中，我们不再硬编码规则，而是利用 Spring 的自动注入（Dependency Injection）特性。
// 1. 注入所有实现了 Customizer 接口的 Bean@ResourceprivateList<AuthorizeRequestsCustomizer>authorizeRequestsCustomizers;@BeanprotectedSecurityFilterChainfilterChain(HttpSecurityhttpSecurity)throwsException{httpSecurity// ... 其他配置 ....authorizeHttpRequests(c->{// 2. 核心逻辑：遍历所有注入的 Customizer，让它们自己定义规则authorizeRequestsCustomizers.forEach(customizer->customizer.customize(c));// 3. 兜底规则（最后执行）c.anyRequest().authenticated();});returnhttpSecurity.build();}解析：主配置类变成了一个“容器”，它根本不知道/order需要什么权限，它只负责把话筒交给各个业务模块，让模块自己“发言”。
2. 标准协议：AuthorizeRequestsCustomizer
我们需要定义一个抽象类，既作为统一的接口类型，又可以提供一些通用的工具方法（如 API 前缀处理）。
publicabstractclassAuthorizeRequestsCustomizerimplementsCustomizer<AuthorizeHttpRequestsConfigurer<HttpSecurity>.AuthorizationManagerRequestMatcherRegistry>,Ordered{@ResourceprivateWebPropertieswebProperties;// 提供通用方法的封装，避免各模块硬编码前缀protectedStringbuildAdminApi(Stringurl){returnwebProperties.getAdminApi().getPrefix()+url;}protectedStringbuildAppApi(Stringurl){returnwebProperties.getAppApi().getPrefix()+url;}// 默认优先级，业务模块可以通过重写此方法调整自己在过滤器链中的位置@OverridepublicintgetOrder(){return0;}}3. 业务实现：模块化的 Customizer
假设我们有一个“基础设施模块 (Infra)”，它需要开放 Swagger 文档和一些监控断点，我们不需要改主工程，只需在 Infra 模块内部写一个 Bean：
@ConfigurationpublicclassInfraSecurityConfiguration{@Bean("infraAuthorizeRequestsCustomizer")publicAuthorizeRequestsCustomizerinfraAuthorizeRequestsCustomizer(){returnnewAuthorizeRequestsCustomizer(){@Overridepublicvoidcustomize(AuthorizeHttpRequestsConfigurer<HttpSecurity>.AuthorizationManagerRequestMatcherRegistry registry){// 定义该模块独有的权限规则registry.requestMatchers(buildAdminApi("/infra/file/**")).permitAll()// 文件下载免登录.requestMatchers("/swagger-ui/**").permitAll()// Swagger 免登录.requestMatchers("/druid/**").hasRole("ADMIN");// 数据库监控需管理员}// 可选：如果需要在其他规则之前生效，可以调高优先级@OverridepublicintgetOrder(){return-10;}};}}三、 工作原理深度解析
这个机制之所以能工作，依赖于 Spring 容器强大的生命周期管理：
- 启动扫描 (Scanning)：
Spring Boot 启动时，扫描所有加了@Configuration的类。 - Bean 注册 (Registration)：
各个业务模块（Infra, Order, Pay）定义的AuthorizeRequestsCustomizer被实例化并注册到 Spring 容器中。 - 依赖收集 (Collection)：
当初始化主配置类YudaoWebSecurityConfigurerAdapter时，@Resource private List<AuthorizeRequestsCustomizer> list这行代码会触发 Spring 去容器里查找所有类型为AuthorizeRequestsCustomizer的 Bean，并将它们装进一个 List 集合中。 - 规则应用 (Application)：
在构建SecurityFilterChain时，代码遍历这个 List，依次调用customize()方法。 - 最终生效 (Finalization)：
Spring Security 将这些分散定义的规则合并成一个完整的RequestMatcher链条。
四、 优缺点总结
优点
- 开闭原则 (Open/Closed Principle)：对扩展开放（新增模块只需加新 Bean），对修改关闭（无需动主配置）。
- 高内聚：业务模块的权限规则写在业务模块内部，代码物理距离更近，更容易理解。
- 灵活性：通过
Ordered接口，可以精确控制规则的生效顺序（例如：通用黑名单规则优先级最高，普通业务规则优先级居中，兜底规则优先级最低）。
注意事项
- 顺序问题：Spring Security 的匹配原则是“先匹配生效（First Match Wins）”。如果一个优先级高的 Customizer 配置了
/**->permitAll，那么后面所有模块的规则都会失效。因此使用Ordered进行顺序管理至关重要。
