如何理解IoC（Inversion of Control）？

目前也正在学Spring，说一下我整理的理解，对IoC和DI的理解：1. 依赖注入和控制反转是从两个角度表达的同一个概念，前者从Spring角度，后者从调用者角度。2. 控制反转：当某个Java对象（调用者）需要调用另一个Java对象（被调用者，也就是被依赖对象）时，通常调用者会采用“new 被调用者”来创建对象，这样有一个痛点就是增强了调用者和被调用者之间的代码耦合，后期不好维护等等。所以在Spring框架中，对象的实例不再由调用者来创建了，而是由Spring容器来创建，控制权由我们写的代码（new 被调用者）转移到了Spring容器，这就是所谓的控制反转。2. 依赖注入：是从Spring角度看的，Spring容器负责将被依赖对象（被调用者）赋值给调用者，这相当于为调用者注入了它依赖的实例，这就是所谓的依赖注入。[图片]

我试着搜了一下，中文资料基本都把IoC（控制翻转）和DI（依赖注入）混为一谈，就连StackOverflow上的第一位答案也犯了同样的问题（幸好下面有高票的反对评论，否则我的世界观都快坏掉了）
控制翻转是代码复用的一种模式（注意不是设计模式）
一般（非IoC）的复用，通常是用户代码调用组件（任意形式的被复用的代码，本答案中统称为组件）。也就是用户代码解决“Why it works, What to do”，组件解决“How to do”，逻辑的入口是用户代码，
而控制翻转则是组件来调用用户代码，也就是组件解决“Why it works, When to do”，用户代码解决“What to do”，逻辑的入口是组件
下面是除了DI之外的控制翻转的例子
•接口／虚函数 组件调用接口／虚函数，具体由用户代码实现
•发布订阅（事件）模式 组件触发事件，用户代码订阅事件
•回调 用户代码写回调，组件来调用
•几乎所有能被称之为框架的东西 用户代码在规定的地方实现具体业务逻辑，剩下的框架负责