面经策

什么是 Spring Bean？ ​

  • 标签：后端、Spring

🏛 业务架构师 ​

Spring Bean 就是被 IOC 容器创建、装配、管理的对象。一个普通的 Java 类，通过 @Component 声明或 @Bean 方法注册进容器后，它的生老病死就都归容器管了——什么时候创建、注入哪些依赖、是否代理、何时销毁。

关键在于区分**"对象"和"Bean"**：new 出来的只是对象，生命周期自己负责；容器里的 Bean 则享受完整的框架服务（依赖注入、AOP 增强、生命周期回调、作用域控制）。

从业务视角我更关注**"什么该交给容器管"**的判断标准：

  • 有状态还是无状态：业务逻辑类（订单服务、风控规则）做成无状态单例 Bean，收益最大——不用每次创建、天然线程安全、可被 AOP 增强；
  • 有业务身份的才注册：领域模型（订单、商品这种有业务生命周期的实体）不该是 Bean，它们的生灭跟随业务流程，而不是容器；
  • 第三方 SDK 包装：加个注解就能让 SDK 客户端获得统一的生命周期和监控治理，这是集成成本最低的方式。

一句话：Bean 的本质是把"参与业务协作的组件"标准化托管，让团队用统一的心智模型管理所有基础设施与业务服务，降低协作与治理成本。

🏗 系统架构师 ​

Bean 是被容器托管的组件实例：以 BeanDefinition 为元数据（类名、作用域、依赖、初始化方式），由容器负责创建、装配、缓存与销毁。

关键在「什么该是 Bean、什么不该是」——这是我做架构评审的重点：

  • 该是：无状态的服务、仓储与适配器、基础设施客户端（线程池、缓存、MQ producer）——生命周期长、需要装配与横切增强；
  • 不该是：携带业务状态的领域对象（实体、聚合）——它们应随请求与事务产生和消亡，进了容器等于把运行时状态全局化，是并发事故的源头。

区分的本质是依赖与状态的分离：容器管理的是依赖图的节点，而不是业务数据的载体。这也是贫血/充血模型之争里常被忽略的前提——状态对象一旦进容器，充血模型必然翻车。

💻 全栈开发专家 ​

Bean 就是交给 Spring 容器创建和管理的对象。我理解它有两个视角：

容器视角：每个 Bean 在容器里是一条 BeanDefinition 元数据——class、scope、lazy、initMethod、dependsOn 等。启动时配置类先被解析成 BeanDefinition 注册进 BeanDefinitionMap，refresh() 末尾才统一实例化。这也解释了为什么同一个类能通过 @Component、@Bean、@Import 多种途径注册。

使用视角：容器负责实例化、依赖注入、初始化回调、销毁回调，默认 singleton 放单例池复用。判断一个对象"是不是 Bean"看它怎么来的——手动 new 出来的脱离容器管理，@Transactional 等注解统统不生效，这就是自调用事务失效的经典根因（拿到的是 this 不是代理 Bean）。

工程上我常用的两个观察手段：Actuator /actuator/beans 看全量清单；启动加 --debug 看条件装配报告（Positive/Negative match），某个自动配置为什么没生效一目了然。多实现冲突报 NoUniqueBeanDefinitionException 时，用 @Primary/@Qualifier 收敛。