Spring中是否应为SimpleUrlAuthenticationFailureHandler创建Bean？

嘿，这个问题问得非常到位！你倾向于用@Bean注入的方式完全符合Spring的最佳实践，下面我给你拆解几个核心原因，方便你跟同事清晰解释：

1. 让Spring容器接管实例，享受生态红利 #

• 直接new SimpleUrlAuthenticationFailureHandler()创建的实例完全脱离Spring容器的管控：它不会触发Spring的生命周期回调（比如@PostConstruct、@PreDestroy），也无法注入任何Spring管理的依赖（比如日志组件、配置属性）。如果后续你需要给这个Handler添加依赖，直接new的方式会让代码变得混乱，而@Bean方式只需要在Bean定义方法里注入对应依赖即可。
• 默认情况下，@Bean创建的是单例实例，整个应用中只会初始化一次，避免了重复创建对象的资源浪费。而直接new的话，每次调用安全配置方法都会生成一个新实例，即便这个Handler本身无状态，也不符合Spring的设计理念。

2. 提升代码的可测试性与扩展性 #

• 测试场景下，@Bean方式可以轻松替换实例：比如你要模拟认证失败的特殊场景，只需要在测试配置类里重新定义这个Bean的mock实现即可。而直接new的话，你要么修改原代码，要么用反射硬替换，测试成本高很多。
• 后续如果需要替换Handler实现（比如自定义一个继承自SimpleUrlAuthenticationFailureHandler的子类），@Bean方式只需要修改配置类中的Bean定义，所有依赖这个Handler的地方都会自动更新，不需要逐个修改new的位置，维护性拉满。

3. 保持代码的一致性与可读性 #

• Spring应用的核心就是依赖注入，把所有可复用组件交给容器管理是团队协作的约定俗成。其他开发者看到@Autowired注入的Handler，能立刻明白这是Spring管理的组件，而直接new的写法会让人困惑：这个实例是不是有特殊初始化逻辑？为什么不交给容器？
• 将Bean定义集中在配置类里，符合关注点分离原则：配置类负责组件的创建与配置，WebSecurityConfigurerAdapter只专注于安全规则的定义，职责划分更清晰，代码结构更整洁。

小补充 #

如果当前这个Handler确实不需要任何依赖，也不会被其他地方复用，直接new好像也能运行，但从长远维护和扩展性来看，@Bean的方式依然是更优选择——它给未来的需求变化留足了空间。

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