以下几点:

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

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

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

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

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

两件事:

它们需要额外的工具支持来检查配置是否有效。

例如，IntelliJ(商业版)支持检查Spring配置的有效性，并将标记出配置中的类型违反等错误。如果没有这种工具支持，就无法在运行测试之前检查配置是否有效。

这就是为什么“蛋糕”模式(Scala社区所熟知)是一个好主意的原因之一:组件之间的连接可以由类型检查器检查。而注释或XML则没有这种好处。

这使得程序的全局静态分析非常困难。

像Spring或Guice这样的框架很难静态地确定容器创建的对象图将是什么样子。尽管它们在容器启动时创建了一个对象图，但它们没有提供有用的api来描述将要创建的对象图。

仅仅通过实现依赖注入就实现了代码的解耦，而没有实际解耦。我认为这是DI最危险的地方。

基于构造函数的依赖注入(没有神奇的“框架”的帮助)是构造OO代码的一种干净而有益的方式。在我所见过的最好的代码库中，经过多年与Martin Fowler的其他前同事的相处，我开始注意到大多数以这种方式编写的优秀类最终都只有一个doSomething方法。

那么，主要的缺点是，一旦您意识到这只是一种笨拙的、冗长的OO方式，将闭包编写为类，以获得函数式编程的好处，那么您编写OO代码的动机就会迅速消失。

控制反转(不是完全依赖注入，但已经足够接近了)最大的“缺点”是，它倾向于去掉一个点来查看一个算法的概述。这基本上就是当你有解耦的代码时所发生的事情——在一个地方查看的能力是紧密耦合的产物。