在阅读了这里的一些相关帖子并在团队中进行了进一步讨论后，我们得出以下结论。我希望这对其他人有用。
关于 XML 配置（我们到目前为止正在使用它），我们决定将其保留为库定义的依赖项（无论是由我们还是第三方开发）。
根据定义，库提供特定的功能，可以在各种场景中使用，不一定涉及 DI。因此，在我们自己开发的库项目中使用注释，会创建 DI 框架（在我们的例子中是 Spring）对库的依赖，使得该库在非 DI 上下文中无法使用。在我们的团队中，拥有额外的依赖关系并不被认为是一个好的做法（总的来说，恕我直言）。
当我们组装应用程序时，应用程序上下文将定义必要的依赖项。当应用程序成为组合所有引用组件的中央单元时，这将简化依赖性跟踪，并且通常这确实是所有接线应该发生的地方。
当为许多组件提供模拟实现而无需重新编译将使用它们的应用程序模块时，XML 对我们也有好处。这为我们在本地或生产环境中测试运行时提供了灵活性。
关于注释，我们决定，当注入的组件不会变化时，我们可以受益于使用它们——例如，在整个应用程序中仅使用组件的特定实现。
注释对于小型组件/应用程序非常有用，这些组件/应用程序不会立即更改或支持依赖项的不同实现，并且不太可能以不同的方式组成（例如，为不同的构建使用不同的依赖项）。简单的微服务就属于这一类。
由注释组成的足够小的组件可以在不同的项目中开箱即用，无需相应的应用程序在其 XML 配置中覆盖它们。这将简化应用程序的应用程序依赖性连接并减少重复设置。
然而，我们一致认为，此类组件应该具有在我们的技术文档中详细描述的依赖关系，以便在组装整个应用程序时，无需滚动代码，甚至无需在 IDE 中加载模块，就可以了解这些依赖关系。
注解配置的组件的一个负面影响是，不同的组件可能会带来冲突的传递依赖性，并且再次由最终应用程序来解决冲突。当这些依赖关系没有在 XML 中定义时，冲突解决方法就会变得非常有限，并且偏离最佳实践（如果可能的话）。
因此，在使用注释时，组件必须足够成熟，了解它将使用哪些依赖项。
一般来说，如果我们的依赖关系可能因不同场景而异，或者模块可以与不同组件一起使用，我们决定坚持使用 XML。显然，必须有一个right两种方法之间的平衡，以及用法的清晰想法。
关于混合方法的重要更新。最近，我们有一个为 QA 团队创建的测试框架的案例，它需要来自另一个项目的依赖项。该框架被设计为使用注释方法和Spring配置类，而引用的项目有一些我们需要引用的xml上下文。不幸的是，测试类（我们使用的org.testng具有 spring 支持）只能与 xml 或 java 配置类一起使用，而不能混合两者。
这种情况说明了混合方法会发生冲突的情况，显然必须放弃其中一种方法。在我们的例子中，我们迁移了测试框架以使用 spring xml 上下文，但其他用途可能意味着相反的方式。
