为 DI 标记接口的默认实现是库的反模式吗？

如何解决为 DI 标记接口的默认实现是库的反模式吗？

我一直认为依赖注入和构建组合根是为了在创建组合根的应用程序的范围内控制依赖关系，但我最近在我的专业人士中遇到了一种情况客户对其 DI 使用（大量）自定义机制的生活，其中之一扫描特定属性，库使用该属性来声明哪个类是给定接口的“正确”实现。

据推测，这样做是为了随着库改变它们的实现，它减少了必须更新各种应用程序中的组合根的维护负担，而人们只需要拉出一个新版本的包并继续自己的快乐之路。对我来说，这感觉基本违反了组合根的概念，因为它消除了决定将哪些实现用于哪些接口的权力，而且我个人拒绝必须对组合根执行基本更新的前提是维护负担，而不是有意识地意识到应用程序中的某些内容何时发生变化是维护人员的期望。这并不是说我反对自动发现和注册，因为它是维护数百行组合代码的巨大力量倍增器，但我确实相信自动发现应该是组合应用程序的行为，而不是它的依赖关系是必要的。

我是否被这种信念误导了？这是记录在案的反模式吗？如果是，那么更好的行业标准替代方案是什么？