当第一次遇到控制反转（IoC）时，它可能非常令人困惑。
这是怎么一回事？它解决了哪个问题？什么时候使用合适，什么时候不合适？
当前回答
在类中创建对象称为紧密耦合，Spring通过遵循设计模式（DI/IOC）来消除这种依赖性。在其中类的对象是传入构造函数而不是在类中创建的。此外，我们在构造函数中提供了超类引用变量，以定义更一般的结构。
其他回答
假设你是一个物体。然后你去餐馆：
没有IoC：你要求“苹果”，当你要求更多时，你总是得到苹果。
与IoC：你可以要求“水果”。每次上桌你都可以得到不同的水果。例如，苹果、橙子或西瓜。
所以，很明显，当你喜欢品种时，IoC是首选。
IoC是关于颠倒代码和第三方代码（库/框架）之间的关系：
在正常的软件开发中，您编写main（）方法并调用“library”方法。您可以控制：）在IoC中，“框架”控制main（）并调用您的方法。该框架处于受控状态：(
DI（依赖注入）是关于控件在应用程序中如何流动的。传统的桌面应用程序具有从应用程序（main（）方法）到其他库方法调用的控制流，但DI控制流是反向的，框架负责启动应用程序、初始化应用程序并在需要时调用方法。
最终，你总会赢：）
控制反转是当程序回调时得到的结果，例如gui程序。
例如，在旧学校菜单中，您可能有：
print "enter your name"
read name
print "enter your address"
read address
etc...
store in database
从而控制用户交互的流程。
在GUI程序或类似程序中，我们会说：
when the user types in field a, store it in NAME
when the user types in field b, store it in ADDRESS
when the user clicks the save button, call StoreInDatabase
所以现在控制反转了。。。代替计算机以固定的顺序接受用户输入，用户控制输入数据的顺序以及数据保存在数据库中的时间。
基本上，任何带有事件循环、回调或执行触发器的东西都属于这一类。
我觉得用这么多先前的答案回答这个问题有点尴尬，但我只是觉得任何答案都没有足够简单地说明这个概念。
所以我们开始。。。
在非IOC应用程序中，您需要对流程进行编码，并在其中包含所有详细步骤。考虑一个创建报告的程序，它将包含设置打印机连接、打印页眉、遍历详细记录、打印页脚、可能执行页面馈送等的代码。
在IOC版本的报告程序中，您将配置一个通用的、可重用的报告类的实例，即一个包含打印报告的过程流但其中没有任何详细信息的类。您提供的配置可能使用DI来指定报告应该调用哪个类来打印标题、报告应该调用什么类来打印详细信息行、，以及Report应该调用什么类来打印页脚。
因此，控制反转来自控制过程，而不是代码，而是包含在一个外部的、可重用的类（Report）中，该类允许您指定或注入（通过DI）报告的详细信息-页眉、详细信息行和页脚。
通过提供不同的细节类集，可以使用同一Report类（控制类）生成任意数量的不同报告。您通过依赖Report类来提供控件，而只是通过注入来指定报表之间的差异，从而实现了控件的反转。
在某些方面，IOC可以与驱动器备份应用程序相比较-备份总是执行相同的步骤，但备份的文件集可能完全不同。
现在具体地回答最初的问题。。。
这是怎么一回事？IOC依赖于一个可重用的控制器类，并提供针对当前问题的详细信息。它解决了哪个问题？防止您必须重述控制流程。什么时候使用合适，什么时候不合适？无论何时创建控制流始终相同且仅更改细节的流程流。在创建一次性自定义流程时，您不会使用它。
最后，IOC不是DI，DI也不是IOC——DI通常可以在IOC中使用（为了说明抽象控制类的细节）。
无论如何，我希望这有帮助。
维基百科文章。对我来说，控制反转就是将您按顺序编写的代码转换为委托结构。您的程序不是显式地控制一切，而是设置一个类或库，其中包含发生某些事情时要调用的某些函数。它解决了代码重复。例如，在过去，您可以手动编写自己的事件循环，在系统库中轮询新事件。现在，大多数现代API只需告诉系统库您感兴趣的事件，它会让您知道它们何时发生。控制反转是减少代码重复的一种实用方法，如果您发现自己复制了整个方法，只更改了一小段代码，可以考虑使用控制反转来解决它。在许多语言中，通过委托、接口甚至原始函数指针的概念，控制反转变得容易。它并不适合在所有情况下使用，因为这样编写时，程序的流程可能更难遵循。在编写可重用的库时，这是一种设计方法的有用方法，但除非它真的解决了代码重复问题，否则应该在自己程序的核心中谨慎使用。
