但是spring文档说它们是一样的。

http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-introduction

在第一行“IoC也被称为依赖注入(DI)”。

源

IoC(控制反转):这是一个通用术语，以多种方式实现(事件，委托等)。

依赖注入:依赖注入是IoC的一个子类型，通过构造函数注入、setter注入或接口注入实现。

但是，Spring只支持以下两种类型:

Setter Injection Setter-based DI is realized by calling setter methods on the user’s beans after invoking a no-argument constructor or no-argument static factory method to instantiate their bean. Constructor Injection Constructor-based DI is realized by invoking a constructor with a number of arguments, each representing a collaborator.Using this we can validate that the injected beans are not null and fail fast(fail on compile time and not on run-time), so while starting application itself we get NullPointerException: bean does not exist. Constructor injection is Best practice to inject dependencies.

关于这个问题，我想说维基已经提供了详细易懂的解释。我引用这里最重要的。

国际奥委会的实施

在面向对象编程中，有几种基本的技术来实现 实现控制反转。这些都是: 使用依赖注入，用于 构造函数注入参数注入Setter注入 接口注入; 使用上下文化查找; 采用模板法设计模式; 使用策略设计模式

至于依赖注入

依赖注入是一种技术，一个对象(或静态的 方法)提供了另一个对象的依赖关系。依赖关系是 可以使用的对象(服务)。注入是传递 对使用它的依赖对象(客户端)的依赖。

//ICO, DI,10年前，他们是这样的:

public class  AuditDAOImpl implements Audit{

    //dependency
    AuditDAO auditDAO = null;
        //Control of the AuditDAO is with AuditDAOImpl because its creating the object
    public AuditDAOImpl () {
        this.auditDAO = new AuditDAO ();
    }
}

现在有了Spring 3,4或最新版本，如下图所示

public class  AuditDAOImpl implements Audit{

    //dependency

     //Now control is shifted to Spring. Container find the object and provide it. 
    @Autowired
    AuditDAO auditDAO = null;

}

总的来说，控件从耦合代码的旧概念倒向了使对象可用的Spring等框架。据我所知，这就是IOC和依赖注入我们使用构造函数或setter将依赖对象注入到另一个对象。注入基本上意味着将它作为参数传递。在spring中，我们有基于XML和注释的配置，我们定义bean对象，并通过构造函数或setter注入样式传递依赖对象。

DI是IoC的一个子集

IoC means that objects do not create other objects on which they rely to do their work. Instead, they get the objects that they need from an outside service (for example, xml file or single app service). 2 implementations of IoC, I use, are DI and ServiceLocator. DI means the IoC principle of getting dependent object is done without using concrete objects but abstractions (interfaces). This makes all components chain testable, cause higher level component doesn't depend on lower level component, only from the interface. Mocks implement these interfaces.

以下是一些实现IoC的其他技术。

IoC概念最初出现在过程式编程时代。因此，从历史背景来看，IoC讨论了控制流所有权的倒置，即谁拥有以所需顺序调用函数的责任——无论是函数本身还是应该将其倒置到某个外部实体。

However once the OOP emerged, people began to talk about IoC in OOP context where applications are concerned with object creation and their relationships as well, apart from the control-flow. Such applications wanted to invert the ownership of object-creation (rather than control-flow) and required a container which is responsible for object creation, object life-cycle & injecting dependencies of the application objects thereby eliminating application objects from creating other concrete object.

从这个意义上讲，DI与IoC不同，因为它不是关于控制流的，但是它是一种Io*，即对象创建的所有权倒置。

我解释DI和IoC的方式有什么问题?