@scope 注解不支持运行时动态切换 bean 生命周期模型，因其作用域在容器启动时解析并固化为 beandefinition 的 scope 属性，运行时修改无效；替代方案包括自定义 scope、objectfactory、@lookup 方法及 aop 代理等。
@Scope 注解本身不支持运行时动态切换 Bean 的生命周期模型。它在 Spring 容器启动时（即 BeanDefinition 解析阶段）就已确定作用域，编译期或配置期静态声明，无法在应用运行过程中通过修改 @Scope 值来改变已有 Bean 实例的作用域行为。
为什么 @Scope 不能动态生效
Spring 在容器刷新（refresh）阶段完成 BeanDefinition 的注册与解析，@Scope 的值（如 "singleton"、"prototype"）被读取并固化为 BeanDefinition 的 scope 属性。后续获取 Bean 时，容器依据该静态配置决定是复用实例还是新建实例。运行时修改注解属性不会触发 BeanDefinition 重解析，也不影响已创建的 Bean 实例或代理逻辑。
替代方案：实现运行时作用域决策
若需根据请求上下文、用户角色、参数等条件动态决定 Bean 实例的复用策略，可采用以下方式：
- 使用自定义 Scope：实现 org.springframework.beans.factory.config.Scope 接口，将作用域逻辑委托给运行时可变的状态（如 ThreadLocal、RequestAttributes、Session、或外部配置中心）。例如，实现一个“tenant”作用域，按租户 ID 隔离单例实例。
-
结合 ObjectFactory 或 Supplier：将原型 Bean 封装在工厂类中，由业务代码按需调用 getObject() 创建新实例；或注入 Supplier
，每次 get() 触发新实例化。 - 利用 @Lookup 方法（适用于原型 Bean）：在单例类中声明抽象方法并标注 @Lookup，Spring 会在运行时注入一个能返回新原型实例的方法实现。
- 基于 AOP + 代理 + 上下文判断：对目标 Bean 使用 ScopedProxyMode.TARGET_CLASS 创建代理，配合自定义 Scope 实现，在代理的 get() 方法中根据当前条件决定返回缓存实例还是新建实例。
常见误用提醒
以下做法无效或危险：
- 试图通过反射修改 BeanDefinition 的 scope 字段 —— 容器已初始化完成，修改不生效且破坏一致性。
- 在 @Scope 中写 SpEL 表达式（如 @Scope("#{T(java.lang.Math).random() > 0.5 ? 'singleton' : 'prototype'}")）—— SpEL 在解析期求值一次，仍是静态结果，非运行时动态切换。
- 依赖 @RefreshScope（Spring Cloud）期望它改变 @Scope 语义 —— @RefreshScope 是针对配置刷新后重建 Bean 的机制，仅适用于特定场景（如配置变更），且重建的是整个 Bean，不是作用域模型的实时切换。
推荐实践路径
明确区分“作用域”和“实例策略”：
- 若只是需要按条件获取不同实例，优先用工厂模式或构造参数区分，而非强行改造作用域。
- 若确需多租户/多环境隔离的“伪单例”，实现 CustomScope 并注册到 ConfigurableBeanFactory。
- Web 环境下善用 request/session scope，它们天然绑定 HTTP 生命周期，无需手动管理。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
