官方为何不推荐使用 @Autowired ？

在 Java 开发中，@Autowired 注解是用于自动装配依赖的常见方式。然而，官方却在某些情况下不推荐使用它，这背后有着一系列重要的原因。

@Autowired 可能导致依赖关系的不明确性。当多个候选的依赖对象存在时，它可能会引发不确定性和难以预测的行为。这使得代码的维护和理解变得更加困难，尤其是对于新加入项目的开发者来说，可能会因为不清晰的依赖关系而感到困惑。

过度依赖 @Autowired 可能会降低代码的可测试性。在单元测试中，由于自动装配的特性，难以对依赖进行有效的模拟和控制，从而影响测试的覆盖度和准确性。这对于保障代码质量和稳定性是不利的。

@Autowired 可能隐藏了潜在的错误。例如，如果依赖的对象未能成功注入，可能会在运行时才抛出异常，而不是在编译时被捕获。这增加了调试和发现问题的难度，降低了开发效率。

从设计原则的角度来看，显式地注入依赖更符合“控制反转”和“依赖注入”的原则。通过显式地声明依赖，代码更加清晰地表达了其结构和需求，增强了代码的可读性和可维护性。

然而，这并不意味着 @Autowired 完全没有用武之地。在一些简单的场景中，它可以提供一定的便利。但在复杂的项目架构和对代码质量要求较高的情况下，官方更倾向于开发者采用更加明确和可控的依赖注入方式。

官方不推荐使用 @Autowired 并非是要完全摒弃它，而是希望开发者能够更加谨慎地考虑依赖注入的方式，选择最适合项目需求和代码质量要求的方法。在追求高效开发的也要注重代码的可维护性、可测试性和可读性，以构建更加健壮和可持续的软件系统。