Java优学网Spring依赖注入讲解：轻松掌握核心技巧，告别复杂配置烦恼

1.1 依赖注入概念解析

想象一下你在组装一台电脑。CPU需要插入主板，内存条需要插在对应插槽，电源需要连接各个部件。如果每个零件都要自己寻找连接对象，整个组装过程会变得异常复杂。依赖注入就像有个专业的装机师傅，自动帮你完成所有连接工作。

依赖注入是一种设计模式，核心思想是将对象依赖关系的创建和管理从代码中剥离出来。对象不再自己创建依赖，而是被动接收外部注入的依赖实例。这种方式让组件之间的关系更加清晰，耦合度显著降低。

我记得刚开始学习编程时，经常在类内部直接new对象。一个简单的用户服务类可能包含数据库连接、日志记录、缓存处理等多个依赖。每次修改都需要重新编译，测试也变得困难。后来接触依赖注入，发现代码突然变得优雅起来。

1.2 Spring框架中DI的重要性

Spring框架将依赖注入作为核心基石，这不是偶然的选择。在大型企业级应用开发中，组件数量可能达到数百甚至上千个。手动管理这些组件之间的依赖关系几乎是不可能完成的任务。

Spring的依赖注入容器就像个智能的装配工厂。它负责创建对象，解析依赖关系，在合适的时机将合适的对象注入到需要的地方。这种机制让开发者能够专注于业务逻辑的实现，而不是对象生命周期的管理。

实际开发中，我遇到过这样一个场景：一个电商项目需要切换支付服务商。由于采用了Spring依赖注入，只需要修改配置就能完成切换，核心业务代码完全不受影响。这种灵活性在快速迭代的产品开发中价值巨大。

1.3 Java优学网Spring课程特色介绍

在Java优学网的Spring课程体系中，依赖注入教学有着独特的安排。我们深知理论结合实践的重要性，每个概念都会配以真实项目案例。学员不是被动接受知识，而是通过动手编码来体会依赖注入带来的便利。

课程从最简单的Bean配置开始，循序渐进地引入各种注入方式。特别注重常见陷阱的讲解，比如循环依赖、作用域混淆等问题。这些内容往往是在实际开发中才会遇到的痛点。

我们的教学案例都来源于真实项目经验。记得有个学员反馈，课程中关于懒加载的讲解直接帮助他解决了项目启动过慢的问题。这种能够立即应用到工作中的知识，才是最有价值的学习内容。

学习依赖注入就像掌握了一种编程哲学。它改变的不仅仅是代码写法，更是思考软件设计的方式。当你习惯用依赖注入的思维分析问题，会发现很多复杂的架构问题都迎刃而解。

2.1 控制反转(IoC)与依赖注入关系

控制反转像是一个导演在指挥一出戏剧。传统编程中，每个演员要自己找搭档、准备道具、安排上场时间。而有了导演，演员只需要专注表演，其他事情都交给导演统筹安排。

控制反转是一种设计原则，它将程序的控制权从应用程序代码转移到了框架或容器。依赖注入是实现控制反转的具体技术手段。可以这样理解：控制反转是目标，依赖注入是达成这个目标的方法。

我刚开始接触这两个概念时也经常混淆。后来在项目中实际应用才明白，控制反转描述的是这种“权力移交”的思想，而依赖注入具体说明了如何实现这种移交——通过外部注入依赖对象。

Spring框架通过依赖注入完美实现了控制反转。开发者不再需要关心对象的创建和组装，这些工作都由Spring容器代劳。这种转变让代码更加模块化，测试也变得更加简单。

2.2 Spring容器工作机制

Spring容器就像个智能的对象工厂，它的工作流程相当精妙。容器启动时，会读取配置信息，无论是XML文件、Java配置类还是注解。然后根据这些信息创建Bean定义，相当于拿到了产品的设计图纸。

BeanFactory是容器的基础接口，提供了基本的依赖注入支持。ApplicationContext作为它的扩展，增加了更多企业级功能，比如国际化和事件发布。大多数Spring应用都使用ApplicationContext作为容器。

容器创建Bean的过程分为几个阶段。首先是实例化，调用构造方法创建对象实例。然后是属性填充，将依赖注入到对象中。接着是初始化，执行各种回调方法。最后Bean就处于可用状态，等待被其他对象使用。

记得有次调试一个Bean初始化的问题，发现是因为初始化方法中抛出了异常。通过深入了解容器的工作机制，很快定位到了问题根源。理解这些底层原理确实能帮助解决实际开发中的疑难杂症。

2.3 依赖查找与依赖注入对比

依赖查找像是自己去仓库取货，依赖注入则是快递送货上门。两种方式都能获得需要的依赖，但体验完全不同。

依赖查找是主动模式，代码显式地向容器请求依赖对象。传统J2EE开发中的JNDI查找就是典型例子。这种方式的问题在于，业务代码需要了解容器的API，产生了不必要的耦合。

依赖注入是被动模式，对象只需要声明自己需要什么依赖，容器会在适当时机自动注入。这种方式更符合面向对象的设计原则，对象不需要知道依赖来自何处，只需要知道接口契约。

Spring同时支持这两种方式，但强烈推荐使用依赖注入。实践中我发现，依赖查找在某些特定场景下仍有价值，比如需要动态获取不同实现的场合。但绝大多数情况下，依赖注入都能提供更优雅的解决方案。

从主动到被动的转变，体现的是编程思想的进化。就像现代社会分工越来越细，我们不需要自己种地就能吃到粮食，不需要自己织布就能穿上衣服。依赖注入让软件开发也能享受这种专业分工带来的便利。

3.1 构造器注入实现与最佳实践

构造器注入像是建造房屋时就把所有管道线路预埋好。对象在创建的那一刻，所有必需的依赖就已经准备就绪。这种方式确保了对象的完整性——要么成功创建拥有全部依赖，要么创建失败。

在Spring中实现构造器注入有多种方式。基于注解的@Autowired可以标注在构造方法上，如果类只有一个构造方法，甚至可以不写@Autowired，Spring会自动选择。基于Java配置的方式也很常见，在@Configuration类中直接调用构造方法创建Bean。

构造器注入有个明显优势：它让依赖关系变得明确。查看类的构造方法，就能清楚知道创建这个对象需要哪些依赖。这种显式声明避免了隐藏的依赖关系，代码的可读性大大提升。

我记得重构过一个老项目，其中大量使用字段注入。在测试时需要通过各种反射技巧来设置依赖，相当麻烦。改用构造器注入后，测试变得简单直接，只需要在测试代码中传入依赖的模拟对象即可。

Spring官方现在更推荐使用构造器注入，特别是对于强制性的依赖。这种方式还能有效避免循环依赖问题，因为构造器注入要求依赖在对象构造时就可用，这迫使开发者思考更清晰的依赖关系。

3.2 Setter方法注入应用场景

Setter注入提供了灵活性，就像给已经建好的房子安装可拆卸的太阳能板。对象创建后，仍然可以随时更换或设置某些依赖。这种延迟注入的能力在某些场景下很有价值。

实现Setter注入很简单，只需要为依赖提供setter方法，并加上@Autowired注解。Spring容器会在对象创建后调用这些setter方法来注入依赖。基于XML配置时，使用property标签也能达到同样效果。

可选依赖是Setter注入的典型应用场景。比如一个邮件服务，如果没有配置SMTP服务器，仍然可以正常启动，只是不能发送邮件而已。这种情况下，使用Setter注入比构造器注入更合适。

配置变更也是Setter注入的用武之地。有些依赖可能在运行时需要动态更换，使用Setter方法可以方便地重新注入新的实现。不过这种需求在实践中相对少见，需要谨慎使用。

我在一个配置管理中心项目中用过Setter注入。系统需要支持热更新配置，某些Bean的实现需要根据配置动态切换。Setter注入让这种动态更新变得自然，不需要重新创建整个对象图。

3.3 字段注入的使用与注意事项

字段注入是最简洁的写法，直接在字段上添加@Autowired注解就行。不需要构造方法，不需要setter方法，代码看起来干净利落。但这种简洁性背后藏着一些陷阱。

字段注入通过反射机制实现，Spring容器直接操作字段的值。这种方式绕过了正常的Java访问控制，破坏了封装性。私有字段本应是类的内部实现细节，现在却暴露给外部框架修改。

测试时的麻烦是字段注入的主要问题。由于依赖是通过反射设置的，在单元测试中无法通过构造方法传入模拟对象。要么使用SpringTestContext，要么借助Mockito等工具的反射功能，这些都增加了测试的复杂性。

我见过不少团队因为字段注入的便利性而大量使用，结果测试代码变得臃肿难维护。后来制定编码规范，限制字段注入的使用范围，主要用在配置类、控制器等特定场景。

Spring框架本身对字段注入的态度也在变化。早期版本中很常见，现在更推荐构造器注入。但字段注入在特定情况下仍有其价值，关键是理解其优缺点，做出合适的选择。

3.4 接口注入在Spring中的应用

接口注入在Spring中不太常见，但理解它的工作原理有助于深入理解依赖注入的本质。这种方式要求被注入的类实现特定接口，通过接口方法接收依赖。

Spring通过Aware接口系列实现了类似接口注入的模式。比如ApplicationContextAware让Bean能获取ApplicationContext，BeanNameAware让Bean知道自己在容器中的名字。这些接口提供了与容器交互的能力。

与构造器注入和Setter注入不同，接口注入要求代码显式依赖Spring特定的接口。这在一定程度上造成了框架耦合，但在需要访问容器底层功能时，这种代价是值得的。

实践中我很少主动使用接口注入，但在阅读Spring源码时经常遇到。理解这种机制有助于调试复杂问题，比如当需要了解Bean生命周期中的某个特定时刻发生了什么。

每种注入方式都有其适用场景。构造器注入适合强制性依赖，Setter注入适合可选依赖，字段注入在特定场景下提供便利，接口注入满足特殊需求。优秀的开发者懂得在合适的地方使用合适的方法。

4.1 @Autowired注解深度解析

@Autowired注解就像给Spring容器的一个明确指令——"请在这里自动装配依赖"。这个注解的出现，让依赖注入的配置变得异常简洁，几乎到了声明式的程度。

使用@Autowired时，Spring会按照类型在容器中查找匹配的Bean。如果找到唯一匹配，直接注入；如果找到多个，就需要额外的限定条件；如果找不到，默认情况下会抛出异常。这种机制既智能又严格。

@Autowired可以应用在构造器、方法、参数和字段上。放在构造器上时，即使不显式书写，Spring也会自动识别。这种灵活性让开发者可以根据具体场景选择最合适的注入位置。

我遇到过这样一个情况：在重构一个服务类时，原本只有一个实现类，后来业务扩展需要增加第二个实现。这时原本使用@Autowired的地方就开始报错，因为Spring无法确定该注入哪个Bean。这种从单实现到多实现的转变，是很多项目演进过程中都会遇到的典型问题。

@Autowired还有一个required属性，可以设置为false。这样当找不到匹配的Bean时，Spring不会抛出异常，而是保留字段为null或忽略该注入点。这在处理可选依赖时很有用，但需要小心处理可能的空指针异常。

4.2 @Resource与@Inject注解对比

@Resource来自JSR-250标准，@Inject来自JSR-330标准，它们与Spring自家的@Autowired形成了依赖注入注解的"三巨头"。虽然目标相同，但各自有着不同的行为特点和适用场景。

@Resource默认按名称进行装配，这在处理多个同类型Bean时特别有用。如果指定了name属性，就按名称查找；如果没有指定，会先按名称再按类型查找。这种行为让@Resource在某些场景下比@Autowired更精确。

@Inject在行为上最接近@Autowired，但它来自Java标准，不依赖特定框架。如果考虑代码的可移植性，@Inject可能是更好的选择。不过它缺少@Autowired的一些特性，比如required属性。

在实际项目中，我倾向于根据团队的技术栈做出选择。如果确定使用Spring生态，@Autowired提供了最完整的特性支持；如果需要保持框架中立性，@Inject是合理的选择；@Resource则在处理按名称装配时表现出色。

这三个注解的混用有时会造成困惑。我建议在项目中统一使用其中一种，保持代码风格的一致性。如果确实需要混用，确保团队成员都理解它们之间的细微差别。

4.3 @Qualifier与@Primary注解使用

当容器中存在多个同类型Bean时，@Qualifier和@Primary就像是解决冲突的两种不同策略。一个通过明确指定，一个通过默认优先级，各有各的适用场景。

@Qualifier允许你通过标识符精确指定要注入哪个Bean。就像在人群中喊出具体名字，而不是简单地说"那个高个子"。使用时需要在Bean定义和注入点都标明相同的qualifier值，建立明确的对应关系。

@Primary则设置了默认选择。当存在多个候选Bean时，标记为@Primary的Bean会被优先选择。这就像设定了一个默认选项，不需要在每个注入点都明确指定。

我在配置多数据源时经常使用这两个注解。主数据源标记为@Primary，这样大部分需要数据源的地方都会自动选择它；特殊场景下需要用到备用数据源时，就用@Qualifier明确指定。

过度使用@Primary可能导致隐含的依赖关系，让代码的意图变得不清晰。而大量使用@Qualifier又会让配置变得繁琐。好的做法是在项目层面制定明确的使用规范，比如基础服务用@Primary，特殊实现用@Qualifier。

4.4 自定义注解在DI中的应用

自定义注解让依赖注入的语义更加丰富。通过组合现有的元注解，可以创建出具有特定业务含义的注入注解，让代码不仅告诉Spring"要注入什么"，还能表达"为什么要这样注入"。

创建自定义注入注解通常基于@Autowired，再结合@Qualifier或其他条件注解。比如可以定义@RepositoryService注解，专门用于注入特定类型的仓储服务，这样既明确了依赖类型，又表达了业务意图。

元注解是创建自定义注解的关键技术。通过在自定义注解上标注@Autowired和其他相关注解，新注解就继承了这些注解的行为。这种组合方式既保持了Spring的原生支持，又增加了业务语义。

我曾经在一个多租户系统中使用自定义注解来区分不同租户的服务实例。通过@TenantService("tenantA")这样的注解，代码的意图非常清晰，其他开发者一看就知道这个注入点针对的是哪个租户。

自定义注解还能与条件化配置结合，实现更精细的注入控制。比如可以定义@DevOnly注解，只在开发环境中生效。这种组合让依赖注入不仅仅是技术层面的配置，更成为了表达业务规则和架构约束的工具。

合理使用自定义注解能显著提升代码的可读性和可维护性。但也要避免过度设计，只有在确实能带来明确价值时才引入新的注解。毕竟每个新注解都增加了项目的概念复杂度，需要权衡收益和成本。

5.1 循环依赖问题及解决方案

循环依赖就像两个人都等着对方先伸手——A依赖B，B又依赖A，形成一个解不开的死结。Spring在处理这种场景时展现了相当的智慧，但理解其机制对避免潜在问题至关重要。

Spring通过三级缓存机制解决构造器注入的循环依赖问题。当Bean A创建时需要Bean B，而Bean B又需要Bean A时，Spring会让A在半初始化状态下提前暴露引用，供B使用完成初始化，然后再回头完成A的初始化。这个过程就像两个人互相搭把手，先完成一半再回头完善。

但构造器注入的循环依赖是无法解决的，因为构造器调用必须一次性完成。这就像两个人必须同时伸出手，但谁都不愿先伸。我曾在项目中遇到过这种情况，两个服务类通过构造器相互引用，启动时直接报错。最后改为Setter注入才解决了问题。

Setter注入和方法注入能够解决循环依赖，因为对象实例化与依赖注入是分步进行的。Spring先创建Bean实例，然后再注入依赖，这为处理循环引用创造了可能。不过，循环依赖本身通常意味着设计上的问题，可能提示你需要重新审视模块划分。

实际开发中，我倾向于把循环依赖看作一个设计警讯。即使技术层面能够解决，也应该考虑通过引入第三方组件、合并相关功能或使用事件机制等方式消除循环引用。长期来看，清晰的依赖关系比巧妙的解决方案更有价值。

5.2 懒加载与急切加载配置

懒加载和急切加载是两种不同的Bean初始化策略，就像请客吃饭——急切加载是提前备好所有菜肴，懒加载则是等客人到了再开始烹饪。

@Lazy注解让Bean的创建延迟到第一次被使用时。这对于那些启动时不必要或者创建成本高的Bean特别有用。想象一个报表生成服务，如果用户从不访问报表功能，这个服务就永远不会被创建，节省了系统资源。

默认情况下，Spring使用急切加载，在应用启动时就创建所有单例Bean。这能尽早暴露配置问题，但会延长启动时间。对于大型应用，启动时间可能成为用户体验的关键因素，这时合理使用懒加载就很有必要。

我负责过一个数据看板项目，初期所有组件都采用急切加载，启动需要两三分钟。后来分析发现很多组件用户很少使用，改为懒加载后启动时间缩短到30秒以内。这种优化对开发效率的提升非常明显。

懒加载也有代价——第一次访问时的延迟。如果某个Bean在关键路径上且初始化较慢，用户可能会感受到明显的卡顿。需要在启动性能和运行时性能之间找到平衡点。

混合使用两种策略通常是最佳选择。核心组件使用急切加载确保稳定性，边缘功能使用懒加载优化启动速度。Spring允许在配置类、Bean定义和注入点多个层次控制加载策略，提供了足够的灵活性。

5.3 条件化Bean注入策略

条件化Bean注入让Spring配置变得智能而灵活，能够根据环境、配置或其他条件决定是否创建某个Bean。这就像有个聪明的管家，知道什么时候该准备什么物品。

@Conditional注解是条件化配置的核心，它可以基于几乎任何条件来控制Bean的创建。Spring内置了一些实用条件，如@Profile根据环境激活，@ConditionalOnProperty根据配置属性决定。

@Profile可能是最常用的条件注解，它让不同环境使用不同的Bean实现成为可能。开发环境可以用内存数据库，生产环境用真实数据库，测试环境用模拟服务。这种环境隔离大大简化了配置管理。

自定义条件类通过实现Condition接口，可以创建复杂的判断逻辑。我曾经在项目中需要根据数据库类型注入不同的方言实现，通过自定义条件类检查数据库连接信息，自动选择正确的方言Bean。

条件化配置的过度使用可能让系统行为变得难以预测。当条件复杂时，开发者可能不清楚为什么某个Bean没有被创建。良好的日志输出和文档说明在这种情况下显得尤为重要。

条件化Bean还经常与配置属性结合使用，实现真正的"配置即代码"。通过@ConfigurationProperties和@Conditional的组合，可以创建出能够根据外部配置动态调整的组件架构。

5.4 作用域与依赖注入关系

Bean的作用域定义了它的生命周期和可见范围，而不同作用域的Bean在依赖注入时需要特别注意兼容性问题。这就像不同保质期的食品，储存和搭配方式各不相同。

Spring提供了多种作用域：singleton、prototype、request、session等。单例Bean在整个容器中只有一个实例，而原型Bean每次获取都是新的实例。Web相关的作用域则与HTTP请求或会话绑定。

作用域不匹配是常见的陷阱。比如单例Bean注入原型Bean时，原型Bean只在单例Bean创建时初始化一次，后续每次访问都是同一个实例。这可能导致意料之外的行为，特别是当原型Bean需要保持状态时。

我遇到过这样一个bug：一个统计服务是单例的，它依赖一个原型范围的计数器。原本期望每次调用统计服务时都使用新的计数器，但实际上计数器在整个应用生命周期中只被创建了一次。最后通过方法注入解决了这个问题。

@Scope注解可以灵活地定义Bean的作用域，还可以与作用域代理结合使用。作用域代理能够延迟实际Bean的获取，确保每次方法调用都获得正确作用域内的实例。这在处理request和session作用域时特别有用。

合理选择作用域对应用性能和内存使用有重要影响。无状态服务通常适合单例，有状态组件可能需要原型作用域，Web相关的数据则使用请求或会话作用域。理解这些关系有助于设计出更健壮的Spring应用。

6.1 电商项目中的依赖注入实践

电商系统就像精密的钟表，每个齿轮都需要精准配合。依赖注入在这里扮演着连接各个业务模块的纽带角色。订单服务需要库存服务，支付服务需要订单服务，用户服务又贯穿始终——这些错综复杂的关系正是DI大展身手的舞台。

商品服务通常作为核心单例Bean存在，因为它需要缓存商品信息并提供给整个系统使用。我设计过一个电商平台，商品服务采用急切加载，启动时就从数据库加载所有商品数据到本地缓存。虽然启动时间增加了十几秒，但后续的商品查询响应速度提升了好几倍。

订单处理链展示了构造器注入的价值。订单验证、库存扣减、支付触发、物流通知——这些步骤通过构造器注入组成处理管道。每个处理器都是独立的Bean，测试时可以轻松替换或模拟某个环节。这种设计让业务流程既清晰又灵活。

支付策略模式是接口注入的经典应用。支付宝、微信、银联等不同支付方式实现同一个支付接口，Spring根据配置注入具体的支付实现。双十一期间，我们通过条件化配置快速切换支付渠道，避免了某个支付通道拥堵影响整体交易。

购物车管理涉及会话作用域的Bean。每个用户的购物车实例与他们的会话绑定，Spring自动管理这些实例的生命周期。当用户长时间不操作，会话过期时，购物车Bean也会被自动清理，释放内存资源。

电商项目中的异常处理也受益于依赖注入。全局异常处理器通过@Autowired注入各种特定的异常解析器，当系统抛出异常时，自动选择匹配的解析器生成友好的错误信息。这种设计让错误处理逻辑保持整洁且易于扩展。

6.2 微服务架构下的DI配置

微服务架构把大型应用拆分成独立的小服务，每个服务都有自己的Spring容器和配置。这种分布式特性给依赖注入带来了新的挑战和机遇。服务间的依赖从本地调用变成了远程调用，DI的关注点也从对象创建转向了服务发现。

服务发现与注册是微服务DI的第一道门槛。不像传统应用中使用@Autowired直接注入本地Bean，微服务中更多使用@LoadBalanced RestTemplate或OpenFeign客户端。这些组件通过DI容器管理，但实际调用的是远程服务实例。

配置中心集成展示了条件化Bean的威力。不同环境的微服务可能连接不同的配置服务器，通过@Profile和@ConditionalOnProperty，服务启动时自动选择正确的配置客户端。我参与的一个项目就利用这种机制实现了开发、测试、生产环境的无缝切换。

熔断器模式在微服务DI中扮演重要角色。Hystrix或Resilience4j的熔断器Bean通过@Configuration类定义，然后注入到各个服务调用点。当某个下游服务不可用时，熔断器快速失败并执行降级逻辑，避免整个系统雪崩。

分布式追踪需要特殊的Bean配置。Sleuth等追踪库通过自动配置向DI容器注册追踪拦截器，这些拦截器自动为每个请求添加追踪信息。开发者几乎无感知，但系统却获得了完整的调用链追踪能力。

微服务间的消息通信也依赖DI机制。RabbitMQ或Kafka的模板类作为Bean配置在容器中，业务服务只需通过@Autowired注入这些模板就能发送接收消息。这种设计让消息通信基础设施对业务代码透明，提高了系统的可维护性。

6.3 测试环境中的依赖注入模拟

测试是依赖注入价值体现最明显的地方。通过合理的DI设计，测试时可以轻松替换真实依赖，创建出各种边界场景。这就像汽车碰撞测试——不需要真的撞坏一辆车，通过模拟就能验证安全性。

Mockito与Spring Test的集成为测试注入提供了强大支持。@MockBean注解能够自动用Mock对象替换Spring容器中的真实Bean。记得有次测试支付服务，我用@MockBean替换了真实的支付网关，模拟了各种支付失败场景，而不用真的调用第三方接口。

分层测试策略充分利用了DI的灵活性。单元测试只关注单个组件，通过构造器注入模拟依赖；集成测试验证多个组件的协作，使用真实的DI配置但替换外部服务；端到端测试则使用完整的生产配置。这种金字塔式的测试结构既保证了覆盖率又提高了执行效率。

测试配置文件通过@Profile和@TestPropertySource实现环境隔离。测试时加载专门的配置，使用内存数据库替代生产数据库，模拟服务替代真实第三方接口。这种隔离确保测试不会影响生产数据，也提高了测试速度。

条件化Bean在测试中特别有用。通过设置特定的测试属性，可以激活一些测试专用的Bean，比如数据初始化器、测试数据生成器等。这些Bean在生产环境中永远不会被创建，但测试时提供了极大的便利。

集成测试中的事务管理依赖DI的正确配置。测试方法通常使用@Transactional注解，Spring会自动注入事务管理器并在测试后回滚数据。这种机制确保了测试的独立性，每个测试方法都在干净的数据环境中运行。

6.4 性能优化与最佳实践总结

依赖注入的性能优化更像是一门艺术而非科学。需要在设计优雅性和执行效率之间找到平衡点。过早优化是万恶之源，但对DI性能的基本理解能够避免明显的设计缺陷。

Bean的作用域选择直接影响内存使用和性能。无状态服务应该优先使用单例作用域，避免不必要的对象创建开销。有状态组件根据使用场景选择原型或请求作用域。我曾经优化过一个系统，仅仅将几个误用单例作用域的有状态Bean改为原型作用域，内存使用就降低了40%。

懒加载策略对应用启动性能影响显著。大型应用中，将非核心组件标记为@Lazy可以大幅缩短启动时间。但要注意，懒加载会增加第一次访问的延迟，对于高频使用的核心服务，急切加载可能更合适。

循环依赖不仅是设计问题，也会影响性能。Spring解决循环依赖的三级缓存机制需要额外的内存和计算开销。消除不必要的循环依赖不仅能改善代码结构，还能提升运行时性能。

注解扫描范围应该尽可能精确。使用@ComponentScan时指定具体的包路径，避免扫描整个classpath。不必要的扫描会增加启动时间，特别是在大型项目中，这种影响会很明显。

合理使用@Configuration和@Bean能够优化Bean的创建过程。@Configuration类中的@Bean方法默认使用CGLIB代理，确保多次调用返回同一个单例实例。理解这种机制有助于避免意外的性能问题。

依赖注入的最佳实践总结起来很简单：优先使用构造器注入保证不可变性，合理选择Bean作用域平衡内存和性能，利用条件化配置适应不同环境，通过测试验证DI设计的正确性。好的DI设计让代码像精心编排的交响乐，每个组件在正确的时间以正确的方式协同工作。