在阅读了此处的一些相关文章并在团队中进行了进一步讨论之后，我们得出以下结论。我希望这对这里的其他人有用。

关于XML配置（我们一直使用到现在），我们决定将其保留为库定义的依赖项（无论是由我们还是由第三方开发）。
顾名思义，库提供了特定的功能，可以在各种情况下使用，而不必涉及DI。因此，在我们自己开发的库项目中使用注释会创建DI框架（在本例中为Spring）对库的依赖，从而使该库在非DI上下文中无法使用。在我们的团队（通常是恕我直言）中，拥有额外的依赖关系不是一个好习惯。

当我们组装一个应用程序时，应用程序上下文将定义必要的依赖关系。当应用程序成为组合所有引用的组件的核心单元时，这将简化依赖关系跟踪，通常这确实是所有连接工作的地方。

在为许多组件提供模拟实现而无需重新编译将使用它们的应用程序模块时，XML对我们也有好处。当在本地或生产环境中运行测试时，这为我们提供了灵活性。

关于注释，我们决定在注入的组件不变的情况下使用它们会受益匪浅-例如，整个应用程序中仅会使用某个组件的特定实现。

注释对于小型组件/应用程序非常有用，这些组件/应用程序不会立即更改或支持依赖关系的不同实现，并且不太可能以不同的方式组成（例如，对不同的构建使用不同的依赖关系）。简单的微服务将适合此类别。

由注解组成的足够小的组件可以在不同的项目中直接使用，而无需使用各自的应用程序以XML配置覆盖它们。这将简化应用程序的应用程序依赖关系布线，并减少重复的设置。

但是，我们同意这些组件应具有我们的技术文档中描述的依赖项，以便在组装整个应用程序时，无需滚动代码甚至在IDE中加载模块，就可以对这些依赖项有所了解。

注释配置的组件的负面影响是，不同的组件可能会带来冲突的传递依赖关系，这又取决于最终的应用程序来解决冲突。如果未在XML中定义这些依赖关系，则冲突解决方法将变得非常有限，并且如果可能的话，它们偏离最佳实践的距离也很远。因此，在使用批注时，组件必须充分了解即将使用的依赖项。

通常，如果我们的依赖性可能因不同的情况而有所不同，或者模块可以与不同的组件一起使用，那么我们决定坚持使用XML。显然，两种方法之间必须有适当的平衡，并且必须有明确的用法构想。

有关混合方法的重要更新。最近，我们为质量保证团队创建了一个测试框架案例，该框架需要另一个项目的依赖。该框架旨在使用注释方法和Spring配置类，而被引用的项目具有一些我们需要引用的xml上下文。不幸的是，测试类（我们在其中使用org.testng了Spring支持）只能与xml或Java配置类一起使用，而不能将两者混合使用。

这种情况说明了混合使用方法会发生冲突的情况，很明显，必须将其中一种方法丢弃。在我们的案例中，我们迁移了测试框架以使用spring xml上下文，但是其他用途可能意味着相反。