专注于技术分享

方法优点缺点推荐场景标准规范、简单直观、与框架解耦需要 JSR-250 API 依赖（通常 Spring Boot 已包含）绝大多数情况下的首选无需额外注解代码侵入性强，与 Spring 框架耦合老旧项目维护，或有特殊需求时完全无侵入，配置集中方法名是字符串，无编译时检查使用 Java 配置（）创建第三方库的 Bean 或需要保持 POJO 纯净时对于 Spring Boot 应用开发，强烈推荐使用，因为它兼具了优雅、简洁和标准化。

在 Spring Boot 中，根据不同的环境（如devprodtest）加载不同的 Bean 是一个非常常见的需求。实现这一目标的最佳方式是使用。通过@Profile注解，您可以将一个 Bean 的创建与一个或多个特定的 Profile 关联起来。只有当指定的 Profile 处于激活状态时，Spring 容器才会创建该 Bean。下面是如何实现“只在dev环境加载一个 Bean，而在prod环境加载另一个”的具体步骤。

在 Spring Boot 中，可以使用注解来实现“只有在项目中存在某个特定的类时，才创建某个 Bean”的需求。这在处理可选依赖（optional dependencies）时尤其有用，可以让配置根据类路径（classpath）中存在的库动态地调整。的核心作用是，它会在加载配置前检查指定的类是否存在于类路径上。如果类存在，那么该配置（或 Bean）就会被加载；如果不存在，Spring Boot 会安静地跳过它，不会引发任何错误。

在 Spring Boot 框架中，我们可以利用 注解来实现根据配置文件中的属性值来决定是否创建某个 Bean。这是一种实现特性开关（Feature Toggle）的常用且优雅的方式。要实现“只有在 时才创建 这个 Bean”，我们可以按照以下步骤操作：在 或 中定义属性。在您的配置文件中，添加相应的属性： 示例:或者，如果您使用的是 YAML 格式： 示例:当此属性为 时， 将被创建。如果将其设置为 或直接注释掉该行，则 Spring 容器在启动时不会创建这个 Bean。在 类或其

Primary是一个强大而优雅的工具，用于解决依赖注入中的歧义性问题。它通过在 Bean 定义端设立一个“默认选项”，使得注入端的代码可以保持干净和通用，是实现“约定优于配置”思想的一个绝佳体现。

特性@Primary角色设置全局默认值进行局部精确指定决定权Bean 的提供方Bean 的消费方优先级较低较高使用时机当多个实现中有一个是绝大多数情况下的选择时。当需要灵活地在多个实现之间切换，或者需要覆盖@Primary的默认行为时。@Primary和@Qualifier是 Spring IoC 中一对相辅相成的利器，共同解决了依赖注入中的歧义性问题，使得代码既能保持简洁（依赖于默认），又能拥有足够的灵活性（按需指定）。

特性@Primary@Qualifier决定权提供方（Bean 的定义者）消费方（Bean 的使用者）作用范围全局默认。影响所有未明确指定的注入点。局部精确。只影响当前这一个注入点。比喻餐厅菜单上的“本店推荐”菜品点菜时对服务员说“我要那道水煮鱼使用场景当一个接口有多个实现，但其中一个实现是最常用、最标准的。当一个接口有多个实现，消费方需要根据不同的业务场景，灵活选择不同的实现。优先级较低。如果同时使用，@Qualifier的指定会覆盖@Primary的默认。较高。@Primary。

Component用途首选，用于定义Bean的配置类，特别是当Bean之间有依赖关系时。用于普通的业务组件。不推荐在其中定义有相互依赖的@Bean方法。行为通过CGLIB代理，保证@Bean方法调用返回容器中的单例Bean。普通Java方法调用，每次都创建新对象，绕过容器管理。何时使用只要你的配置类里有@Bean方法，特别是它们之间有调用关系，就必须使用。当你的类只是一个简单的业务组件（如Service），或者你的配置类里的@Bean方法完全独立，没有相互调用时（但依然不推荐）。

通用/任何层 | 一个通用的 Spring 管理组件 | 无 || 表现层 (Web Layer) | 一个目标。// 这个切点会匹配所有被 @Service 注解的类中的所有公共方法@Point处理 Web 请求的控制器 | 无（但与 Spring MVC 深度集成）|@Around("service | 业务逻辑层 (Service Layer) | 一个处理业务逻辑的服务 | 无（但常作为 AOP 事务Layer()")// ... 在方法切面的目标）|

概念角色描述依赖注入 (DI)设计模式/原则一种思想：组件的依赖由外部容器来提供，以实现解耦。@Autowired注解/指令Spring 框架中实现 DI 的一种工具，它告诉容器“请在这里注入一个 Bean”。@Autowired是你向 Spring 发出的一个请求，而 Spring 响应这个请求并为你完成依赖的传递，这个过程就是依赖注入。

把整个流程用一个图书馆的比喻开馆准备 (Spring 启动)图书馆管理员（BeanFactory）整理了一份完整的图书目录目录上写着每本书（Bean）的详细信息（读者借书 (第一次调用getBean一个读者想借《Java 编程思想》这本书（管理员首先查看“热门借阅/参考书架”（一级缓存），看上面有没有这本书。没有。管理员于是去查图书目录），找到了这本书的详细信息。他根据信息去书库（JVM 堆）里把这本书的原版）找了出来，并盖上“图书馆藏”的印章（初始化、注入依赖等。

Bean 类型如何成为 Bean？谁负责创建和配置？你的角色你的@Service类通过@Component注解 + 组件扫描Spring 容器（实例化）声明它是候选人DataSource通过@Bean方法（在自动配置类中）Spring Boot 自动配置提供pom.xml和通过@Bean方法（在你自己的配置类中）你（借助 Spring Boot 提供的定义@Bean方法，完成最终创建所以，Starter 的真正魔力在于：它不仅能通过自动配置直接提供“成品”Bean（如DataSource。

Spring Boot 启动时：启动-> 看到主启动类上的。发现-> 从中发现内置的。确定扫描路径-> 将主启动类所在的包作为根路径。执行扫描-> 在这个路径及其子路径下，寻找所有被@Component(及其衍生注解@Service等) 标注的类。实例化和注册-> 将找到的类通过反射创建成实例（Bean），并放入 IoC 容器中。依赖注入-> 在创建 Bean 的过程中，如果发现@Autowired注解，就从容器中找到匹配的 Bean 并注入进去，完成对象之间的“自动装配”。

概念角色作用Spring IoC 容器中央工厂和管理者提供了一个拦截和替换 Bean 的机会点。它是所有高级功能的基础平台。Spring AOP智能改装师 (Proxy Factory)利用 IoC 提供的机会，在不修改源码的情况下，为原始 Bean 创建一个功能增强的代理 Bean。声明式事务一种具体的改装方案AOP 的一个具体应用。通过代理，为业务方法自动包裹上事务开启、提交、回滚的逻辑。

方面推荐方式理由Bean 声明@Service等构造型注解语义清晰、代码可读性高、符合分层架构依赖注入构造函数注入(通常配合 Lombok 的保证依赖不可变 (final)、保证依赖非空、依赖关系清晰、极易进行单元测试遵循这套“黄金组合”，我们的 Spring Boot 应用将会拥有一个清晰、健壮、高内聚、低耦合且易于测试的架构基础。

字符串# 数字# 布尔值# 逗号分隔的列表# 带默认值的属性 (我们在代码中处理)# app.description=... (假设这个属性没有被定义)@Value。

特性纯 Spring 框架Spring Boot 如何简化组件扫描需手动配置或默认扫描主类及其子包，无需配置。依赖管理需手动添加多个 jar 包并处理版本冲突。提供Starters，只需一个依赖即可引入一套功能和兼容的版本。通用 Bean 配置需手动配置DataSource等大量样板 Bean。通过，根据 classpath 自动配置绝大多数通用 Bean。外部配置需手动配置来读取文件。默认支持.yml，直接通过@Value或即可注入。应用启动需手动编写main方法来创建和启动。提供。

注入方式语法数据来源主要用途灵活性属性占位符配置文件、环境变量等将外部配置注入代码，实现代码与配置解耦。非常高SpEL 表达式Bean 属性、方法调用、运算结果执行动态计算，实现更复杂的注入逻辑。极高硬编码值固定的字符串测试或注入不会改变的常量。非常低通过@Value注解，Spring IoC 容器不仅能管理对象之间的依赖关系（@Autowired），还能完美地管理对象与外部配置值之间的关系，从而让我们的应用程序更加健壮、灵活和易于维护。这同样是控制反转。

注解条件主要用途配置文件中属性的值功能开关，按配置切换实现IoC 容器中缺少某个 Bean提供可被用户覆盖的默认实现（兜底 Bean）IoC 容器中存在某个 Bean当某个依赖准备好后，才装配当前 BeanClasspath 中存在某个类检测是否引入了某个依赖库，是开发 starter 的核心当前是 Web 应用环境装配只在 Web 环境下有意义的 Bean自定义Condition类实现高度定制化的、复杂的判断逻辑。

方法用途优点缺点/适用范围隐式依赖(构造函数)[首选]定义 Bean 之间的直接依赖关系最自然、最符合 IoC 思想，代码清晰无法处理没有直接引用的“副作用”依赖@DependsOn[推荐]强制指定初始化顺序，处理“副作用”依赖意图明确，直接解决问题引入了对 Bean 名字的字符串依赖，略有侵入性在所有 Bean 初始化后执行逻辑高度解耦，适用于应用启动后的任务不是控制 Bean 之间的顺序，而是控制逻辑的执行时机控制 Spring Boot 自动配置类的顺序。

解决方案核心思想优点适用场景@Primary“默认选项”消费者代码无感知，配置简单多个实现中有一个是明确的“首选”或“默认”@Qualifier“按名指定”精确，消费者可以灵活选择消费者需要特定实现，或没有默认实现时注入集合ListMap“我全都要”极度灵活，完美支持策略模式需要执行所有实现，或需要动态选择策略时最佳实践建议：优先使用构造函数注入：它能保证依赖在对象创建时就是可用的，并且方便进行单元测试。如果有一个明确的通用实现，使用@Primary是最干净的方案。

作用域范围生命周期共享级别典型用例singletonSpring IoC 容器容器启动到关闭所有请求、所有会话无状态 Service, DAO, 配置类request一次 HTTP 请求请求开始到结束同一请求内的所有组件当前用户信息、请求参数session一个用户会话会话创建到失效同一用户会话内的所有请求购物车、用户登录状态整个 Web 应用应用启动到关闭所有用户、所有会话全局配置、全局缓存、计数器。

singleton和prototype是 Spring 中最基础也是最重要的两种作用域，理解它们的区别有助于我们快速掌握 Spring IoC。

Bean 的作用域（Scope）定义了 Spring IoC 容器如何创建和管理一个 Bean 实例的生命周期和可见范围。当我从容器中请求一个 Bean 时，是每次都创建一个新的实例，还是返回之前已经创建好的同一个实例？Spring 提供了多种作用域，让你可以精确地控制 Bean 实例的行为，以适应不同的业务场景。作用域 (Scope)描述默认?典型用例singleton每个 Spring IoC 容器一个实例是无状态的 Service, Repository, Controller。

干预方式作用阶段影响范围推荐度/适用场景初始化后 / 销毁前单个 Bean强烈推荐，代码清晰，与框架解耦。初始化后 / 销毁前单个 Bean不推荐，与 Spring 强耦合，用于兼容老代码。初始化后 / 销毁前单个 Bean推荐，用于无法修改源码的第三方 Bean。初始化前后所有 Bean高级/框架级。用于实现 AOP、自定义注解处理等全局逻辑。Aware接口初始化前单个 Bean谨慎使用。当 Bean 需要主动与容器交互时使用。

配置元数据] -> [BeanDefinition]v[1. 实例化] (调用构造函数)v[2. 属性填充] (依赖注入)v[3. 初始化]|--> 调用 Aware 接口|--> BeanPostProcessor (After) <-- AOP 代理发生点v[4. Bean 可用] (放入单例池，等待使用)v[5. 销毁] (容器关闭时)

Setter 注入是通过类的公开setXXX()方法来注入依赖。Spring IoC 容器会先调用类的无参构造函数创建一个实例，然后调用相应的 setter 方法将依赖关系注入进去。@Service// Spring容器会调用这个方法来注入一个DataExporter类型的Bean@AutowiredSystem.out.println("通过 setter 注入 DataExporter...");

特性字段注入 (@Autowired on field)构造函数注入 (@Autowired on constructor)简洁性⭐⭐⭐⭐⭐⭐⭐☆☆☆可测试性⭐☆☆☆☆ (极差)⭐⭐⭐⭐⭐ (极好)依赖明确性⭐☆☆☆☆ (隐藏依赖)⭐⭐⭐⭐⭐ (明确暴露)不可变性 (final❌ 不支持✅ 支持容器耦合度高低 (纯 POJO)循环依赖检测可能掩盖问题启动时立即失败 (Fail-Fast)建议：优先使用构造函数注入来注入所有必需的依赖。避免在业务组件（@Service@Component。

方式优点缺点推荐级别构造函数注入依赖不可变、关系明确、保证非空、易于测试、避免循环依赖代码稍多⭐⭐⭐⭐⭐（强烈推荐）Setter 方法注入灵活性高，适用于可选依赖依赖可变，可能为null，隐藏必需依赖⭐⭐☆☆☆ （仅用于可选依赖）字段注入代码最简洁可测试性差、隐藏依赖、与容器强耦合⭐☆☆☆☆（强烈不推荐用于业务代码）

Component及其衍生注解：是“自荐模式类自己说：“我是个 Bean，快来管我！适用于应用内部的、由你控制的组件。@Bean：是“举荐模式配置类说：“我推荐这个方法返回的对象做个 Bean，你来管管它！适用于第三方类复杂创建逻辑或需要精细化控制的场景。在实际开发中，这两种方式通常会混合使用，相得益彰，共同构成了 Spring 强大而灵活的配置模型。

你做什么 (声明)Spring 做什么 (发现和管理)1. 在你的类上添加@Component或其衍生注解 (@Service等)。1. 启动时加载一个配置类 (2. 在配置类上添加，告诉 Spring 从哪里开始扫描。2. 发现注解，获取要扫描的包路径。3. 使用扫描器在指定的类路径下查找所有.class文件。4. 高效读取每个.class文件的元数据（特别是注解）。5. 识别出被@Component等注解标记的类。6. 为每个识别出的类创建一个(Bean 的蓝图/菜谱)。

联系：Bean 的“原材料”就是一个普通的 Java 对象（POJO）。区别：Bean 是被 Spring IoC 容器“收养并赋予超能力”的 POJO。核心：这个区别不在于对象本身的代码，而在于它是否被纳入了 IoC 容器的管理体系。所有的 Spring Bean 都是 Java 对象，但并非所有的 Java 对象都是 Spring Bean。只有那些被 IoC 容器管理起来的，才能被称为 Bean。

简单来说，Spring IoC 容器是一个负责创建、管理和组织应用程序中所有对象（在 Spring 中称为 “Bean”）的超级工厂和管家。你知道家里需要什么（配置信息）：你给管家一份清单（比如 XML 文件或注解），告诉他：“我需要一个厨师（ChefBean），一个司机（DriverBean），并且这个厨师需要一套特定的刀具（另一个KnifeSetBean）。管家负责准备一切（实例化和装配）：管家会按照你的清单，去市场上找到最好的厨师，买来那套刀具，并确保在厨师开始工作前，刀具已经交到他手上（依赖注入）

概念角色回答的问题例子/比喻IoC设计原则/思想“我们应该做什么？-> “我们应该把控制权交出去，以实现解耦。想去一个地方（目标）DI设计模式/实现“我们具体怎么做？-> “通过注入的方式，把依赖传递给对象。坐出租车去那个地方（具体方法）所以IoC 是一种让代码更松耦合的设计理念，而 DI 是实现这一理念最核心、最常用的设计模式。在 Spring 框架中，我们通过 DI 来践行 IoC 的思想。

我们来一步步拆解这个问题。

特性没有 IoC使用 Spring IoC控制权应用程序代码主动创建和控制对象 (newIoC 容器负责创建和管理对象依赖关系编译时静态确定，硬编码在代码里运行时动态注入，配置在容器中耦合度高，类与具体实现紧密绑定低，类只依赖于接口，易于替换可测试性差，难以替换依赖进行单元测试好，可以轻松注入 Mock 对象代码关注点业务逻辑和对象创建逻辑混杂只需关注业务逻辑，代码更简洁所以，Spring IoC 的核心价值在于它通过反转控制权，实现了程序的解耦。