这问题问得太戳中痛点了——我刚从工厂模式转DI的时候也有过一模一样的困惑，心想“明明改工厂方法就能切换实现，DI还要每个项目改实例化，哪里灵活了？”后来踩了不少坑才明白，咱们可能对「现代DI」的理解有点偏差，今天就唠唠这事儿：

1. 你说的“DI”可能是「手动DI」，不是真正的现代DI #

你举的电话接口例子里，提到“使用DI切换API或系统时需修改每个项目的实例化代码”——这其实是手动依赖注入的做法，也就是每个项目自己new实现类然后传给依赖方。但现代DI都是配合DI容器（比如Spring、Autofac、Microsoft.Extensions.DependencyInjection）使用的：

• 你只需要在一个统一的配置点（比如全局的DI注册类、配置文件）里，把ITelephone接口绑定到具体实现（比如NewTelephoneAPI）；
• 所有项目里的业务代码只需要声明依赖ITelephone，容器会自动把实例注入进去，完全不用手动new；
• 要切换实现？只需要改那一处配置，所有项目自动用上新的实现，和工厂模式改工厂方法一样省心，甚至更灵活（比如可以靠配置文件动态切换，不用改代码）。

2. 工厂模式的灵活性有天花板 #

工厂模式确实能解决“统一创建实例”的问题，但遇到复杂场景就容易卡壳：

• 依赖链复杂时：如果ITelephone的实现需要依赖ILogger、IConfigService、ISmsNotification等其他服务，工厂方法里就得手动new这些依赖，或者把它们传到工厂里——这会让工厂类越来越臃肿，耦合越来越高。而DI容器会自动帮你管理整个依赖链，你只需要注册每个服务，容器会递归创建所有依赖的实例。
• 多实现切换逻辑复杂时：你说可以用可选参数给特定项目指定实例，但如果有10种实现、要根据环境（开发/测试/生产）、用户角色、地域等条件动态切换，工厂里就得写一堆if-else或者switch，代码会变得非常难维护。而DI容器可以靠条件注册、命名服务、运行时动态解析来实现，逻辑更清晰，扩展性更强。
• 可测试性差：要测试依赖ITelephone的业务代码时，工厂模式如果是静态工厂或者硬编码的创建逻辑，你得要么改工厂代码，要么用反射来替换实例；而DI直接就能注入Mock对象，测试起来毫无负担。

3. DI的核心是「关注点分离」，而工厂模式还是有耦合 #

工厂模式本质上是把“实例创建逻辑”从业务代码里抽到了工厂类，但业务代码还是要主动调用工厂（比如TelephoneFactory.GetInstance()）——这就意味着业务代码和工厂类还是有耦合。而DI的核心是控制反转（IoC）：业务代码完全不关心实例是怎么来的，只需要声明自己需要什么接口，剩下的全交给容器。这种彻底的解耦，才是DI灵活性的核心：

• 你可以随时替换实现，甚至替换整个依赖链，业务代码完全不用改；
• 你可以在不同环境用不同的实现（比如开发用Mock，生产用真实API），不用修改业务逻辑；
• 你可以轻松扩展新的实现，不用修改现有工厂或业务代码。

4. 二者其实可以共存，不是非此即彼 #

很多场景下，工厂模式可以作为DI的补充：比如某个对象的创建逻辑特别复杂（比如需要根据多个参数动态组装），你可以写一个工厂类，然后把工厂类注册到DI容器里，业务代码依赖工厂，或者让容器通过工厂来创建实例。这样既利用了DI的解耦优势，又用工厂模式处理了复杂的创建逻辑。

总结 #

你觉得DI不灵活，大概率是因为只接触了手动DI，而没用到带容器的现代DI。现代DI的灵活性，体现在更彻底的解耦、更强大的依赖管理、更好的可测试性和扩展性——这些都是工厂模式很难做到的。当然，工厂模式在简单场景下确实够用，但当系统复杂度上来后，DI的优势就会越来越明显。

内容的提问来源于stack exchange，提问作者user2696330