依赖注入是一种技术或模式，与任何框架无关。您可以手动连接依赖项。DI帮助您实现SR(单一职责)和SoC(关注点分离)。DI会带来更好的设计。从我的观点和经验来看，没有坏处。就像任何其他模式一样，你可能会弄错或误用它(但在DI的情况下很难)。

如果您使用框架将DI作为原则引入到遗留应用程序中，那么您可能犯的最大错误就是将其误用为服务定位器。DI+框架本身是伟大的，只是让事情变得更好，我看到它!从组织的角度来看，每一个新的过程、技术、模式……都有共同的问题:

你必须训练你的团队 您必须更改您的应用程序(这包括风险)

一般来说，你必须投入时间和金钱，除此之外，没有任何负面影响，真的!

这更像是吹毛求疵。但是依赖注入的一个缺点是，它使开发工具更难推理和导航代码。

具体来说，如果你在代码中控制-单击/命令-单击方法调用，它将带你到接口上的方法声明，而不是具体的实现。

这实际上是松散耦合代码(由接口设计的代码)的缺点，即使不使用依赖注入(即，即使只是使用工厂)也适用。但是依赖注入的出现真正鼓励了松耦合代码的普及，所以我想我应该提到它。

而且，松散耦合代码的好处远远超过这一点，因此我称之为吹毛求疵。尽管我工作了很长时间，知道如果您试图引入依赖注入，可能会遇到这种情况。

事实上，我敢大胆地猜测，对于依赖注入的每一个“缺点”，您都会发现许多优点远远超过它。

这是我自己的第一反应:基本上任何模式都有同样的缺点。

学习是需要时间的 如果误解了，就会弊大于利 如果走到极端，工作量可能会超过收益

以下几点:

DI增加了复杂性，通常是通过增加类的数量，因为责任分离得更多，这并不总是有益的 您的代码将(在某种程度上)耦合到您使用的依赖注入框架(或者更一般地说，如何决定实现DI模式) 执行类型解析的DI容器或方法通常会导致轻微的运行时损失(非常可以忽略不计，但它确实存在)

通常，解耦的好处是使每个任务更易于阅读和理解，但增加了编排更复杂任务的复杂性。

我发现构造函数注入会导致构造函数又大又丑(我在整个代码库中都使用它——也许我的对象太细了?)此外，有时使用构造函数注入会导致可怕的循环依赖(尽管这种情况非常罕见)，因此您可能会发现自己必须在更复杂的系统中拥有某种就绪状态生命周期，并进行几轮依赖注入。

然而，我更喜欢构造器注入而不是setter注入，因为一旦我的对象被构造，那么我就可以毫无疑问地知道它处于什么状态，它是在单元测试环境中还是加载到某个IOC容器中。这，以一种迂回的方式说，我觉得是setter注入的主要缺点。

(作为旁注，我确实发现整个主题相当“宗教”，但你的成就将随着开发团队的技术狂热程度而变化!)

在过去的6个月里，我一直在广泛使用Guice (Java DI框架)。虽然总的来说我认为它很棒(特别是从测试的角度来看)，但也有一些缺点。最值得注意的是:

Code can become harder to understand. Dependency injection can be used in very... creative... ways. For example I just came across some code that used a custom annotation to inject a certain IOStreams (eg: @Server1Stream, @Server2Stream). While this does work, and I'll admit has a certain elegance, it makes understanding the Guice injections a prerequisite to understanding the code. Higher learning curve when learning project. This is related to point 1. In order to understand how a project that uses dependency injection works, you need to understand both the dependency injection pattern and the specific framework. When I started at my current job I spent quite a few confused hours groking what Guice was doing behind the scenes. Constructors become large. Although this can be largely resolved with a default constructor or a factory. Errors can be obfuscated. My most recent example of this was I had a collision on 2 flag names. Guice swallowed the error silently and one of my flags wasn't initialized. Errors are pushed to run-time. If you configure your Guice module incorrectly (circular reference, bad binding, ...) most of the errors are not uncovered during compile-time. Instead, the errors are exposed when the program is actually run.

既然我已经抱怨过了。让我说，我将继续在我当前的项目中(很可能是在下一个项目中)使用Guice。依赖注入是一种非常强大的模式。但它肯定会让人困惑，无论你选择什么依赖注入框架，你几乎肯定会花一些时间咒骂。

另外，我同意其他发帖者的观点，依赖注入可能被过度使用。