Spring Security 教程（17）、命名空间的设计

为什么 Spring 选择命名空间

Spring 框架的设计理念之一是”约定优于配置”。命名空间配置正是这一理念的体现。

在 Spring Security 早期版本中，开发者需要编写大量的 Java 代码来配置安全策略。对于简单的安全需求，这些代码显得过于冗长。命名空间配置通过 XML 标签提供了更简洁的表达方式。

<!-- 这行 XML 配置，相当于数十行 Java 代码 -->
<security:http auto-config="true" use-expressions="true">
    <security:intercept-url pattern="/admin/**" access="hasRole('ADMIN')"/>
    <security:form-login/>
</security:http>

命名空间 vs Java Config 的对比

特性	XML 命名空间	Java Config
类型安全	否（运行时检查）	是（编译期检查）
重构支持	弱	强
可读性	高（声明式）	中高（代码化）
灵活性	中（固定标签）	高（任意逻辑）
条件配置	困难	容易
测试友好	一般	优秀

命名空间的设计原则

声明式优先：命名空间让安全配置更像声明式的”规则列表”，而不是命令式的”代码逻辑”。

默认值友好：命名空间配置了大量默认值，简单场景下几乎不需要额外配置。

扩展点清晰：命名空间通过 CustomUserTypeDefinitionParser 等机制提供扩展点，允许自定义配置元素。

何时使用命名空间

• 快速原型开发，需要最少配置
• 团队中非 Java 开发人员需要修改安全配置
• 遗留 XML 配置的维护
• 简单安全场景（只需要基本的表单登录和 URL 授权）

何时使用 Java Config

• 需要条件化配置（根据环境、参数动态调整）
• 需要复杂的配置逻辑
• 需要编写单元测试验证配置
• 新项目推荐方式

趋势：Java Config 成为主流

从 Spring Security 4 开始，官方推荐使用 Java Config。命名空间仍然是可选的，但新的特性会优先在 Java Config 中实现。对于新项目，建议直接使用 Java Config。