如何通过运行时参数创建原型作用域@Bean？getBean方式是否合规？

1. 能不能用getBean(String name, Object... args)创建带参数的原型Bean？ #

当然可以！你给出的代码示例是完全可行的——Spring的ApplicationContext.getBean()方法确实支持传入运行时参数，用来创建原型作用域的Bean，并且这些参数会被直接传递到Bean的构造器中（刚好匹配你用构造器注入参数的需求）。

你的代码逻辑没问题：每次调用getBean(Thing.class, name)都会返回一个全新的Thing实例，构造器会拿到你传入的name参数，同时Spring会自动完成SomeComponent和AnotherComponent这些依赖的注入。

2. 为啥Spring IoC文档没重点提及这种方式？ #

核心原因是这种方式违背了控制反转（IoC）的设计初衷。Spring的核心思想是让容器管理Bean的生命周期和依赖注入，业务代码只需要专注于自身逻辑，而不是主动去容器中获取Bean。直接调用getBean()会带来几个问题：

• 代码与Spring容器强耦合，脱离Spring环境就无法运行；
• 单元测试变得繁琐，需要模拟整个ApplicationContext而非简单注入依赖；
• 代码可读性下降，其他开发者需要额外理解你调用getBean()的意图。

所以Spring文档更倾向于推荐解耦的、符合IoC理念的实现方式，而非这种直接操作容器的做法。

3. 这算不算常规实现？有没有更规范的方法？ #

这种getBean()的方式只能算是“可用但不推荐”的临时方案，不属于Spring官方认可的常规实现。下面是几种更规范的替代方案：

方案一：使用ObjectProvider（Spring 4.3+推荐）

ObjectProvider是Spring提供的轻量级依赖查找工具，既避免了直接依赖ApplicationContext，又支持获取原型Bean时传入构造参数：

@Autowired
private ObjectProvider<Thing> thingProvider;

public void onRequest(Request request) {
    String name = request.getParameter("name");
    // 传入构造参数，每次调用返回新的原型实例
    Thing thing = thingProvider.getObject(name);
}

它的优势很明显：

• 耦合度低，仅依赖Spring的抽象接口而非整个容器；
• 支持空安全、可选依赖等实用特性；
• 单元测试时可以轻松模拟ObjectProvider。

方案二：在@Configuration中定义带参数的原型Bean方法

你可以在配置类中定义一个带参数的@Bean方法并标记为原型作用域，然后直接在业务代码中注入这个方法（Spring会自动把它包装成一个“工厂”，每次调用返回新实例）：

@Configuration
public class AppConfig {
    @Bean
    @Scope("prototype")
    public Thing createThing(String name) {
        return new Thing(name);
        // Spring会自动处理Thing中@Autowired标记的依赖注入
    }
}

// 在业务类中注入这个工厂方法（Spring会封装为Function）
@Autowired
private Function<String, Thing> thingFactory;

public void onRequest(Request request) {
    String name = request.getParameter("name");
    Thing thing = thingFactory.apply(name);
}

甚至可以更直接地注入该方法本身：

@Autowired
private Thing createThing(String name);

public void onRequest(Request request) {
    String name = request.getParameter("name");
    Thing thing = createThing(name);
}

方案三：自定义FactoryBean

如果Thing的创建逻辑比较复杂，比如需要多步处理参数，可以自定义FactoryBean来封装创建过程：

public class ThingFactoryBean implements FactoryBean<Thing> {
    @Autowired
    private SomeComponent someComponent;
    @Autowired
    private AnotherComponent anotherComponent;

    // 存储运行时参数
    private String name;

    public void setName(String name) {
        this.name = name;
    }

    @Override
    public Thing getObject() throws Exception {
        // 这里可以添加复杂的创建逻辑
        return new Thing(name);
    }

    @Override
    public Class<?> getObjectType() {
        return Thing.class;
    }

    @Override
    public boolean isSingleton() {
        return false; // 标记为原型作用域
    }
}

在配置类中注册后，业务代码就可以通过它创建原型Bean：

@Configuration
public class AppConfig {
    @Bean
    public ThingFactoryBean thingFactoryBean() {
        return new ThingFactoryBean();
    }
}

// 业务类中使用
@Autowired
private ThingFactoryBean thingFactoryBean;

public void onRequest(Request request) {
    String name = request.getParameter("name");
    thingFactoryBean.setName(name);
    Thing thing = thingFactoryBean.getObject();
}

4. 为啥getBean()的方式非常规？ #

总结一下不推荐的核心原因：

• 强耦合容器：代码必须依赖Spring容器才能运行，失去了业务逻辑的独立性；
• 测试成本高：单元测试时需要模拟整个ApplicationContext，无法做到轻量级测试；
• 违背IoC理念：IoC是让容器主动推送Bean给业务代码，而非业务代码主动去容器中获取；
• 语义不清晰：其他开发者需要额外理解getBean()的调用意图，代码可读性差。

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