1. 为何在Angular中不使用new运算符创建依赖？ #

咱们先拆解这个问题：如果直接用new Dep()来创建依赖，会带来几个核心问题：

• 依赖层级管理噩梦：如果Dep本身还有自己的依赖（比如Dep的构造函数需要AnotherService），那你就得手动new AnotherService()，要是这个依赖链再深一点，代码会变得极其臃肿，维护成本直线上升。Angular的DI容器会自动帮你递归解析所有依赖，你完全不用操心这些细节。
• 无法灵活替换依赖：写单元测试的时候，你想把真实的Dep换成一个模拟（Mock）版本？如果用new的话，你得修改组件里的代码才能做到，这显然违背了测试的原则。而用DI的话，你只需要在测试模块的providers里替换掉依赖的实现就行，组件代码完全不用动。
• 生命周期失控：Angular的DI容器会帮你管理依赖的生命周期（比如单例服务的实例复用）。如果自己new的话，每次都会创建新实例，不仅浪费资源，还可能导致状态不一致的问题——比如你希望某个服务是全局唯一的，手动new根本做不到这一点。

2. 改依赖类名时DI似乎也要改，那它到底怎么解耦？ #

你提到的这个点很有意思，其实这里混淆了依赖的具体实现和依赖的抽象契约：

情况1：直接依赖具体类（比如constructor(private dep: Dep)） #

这种情况下，确实要修改构造函数里的类型声明，但和不用DI的场景比，耦合度已经低很多了：

• 如果不用DI，你得找到所有new Dep()的地方逐个修改，要是这个依赖在10个组件里都被手动实例化过，那你就要改10次；而用DI的话，你只需要修改构造函数的参数类型，以及DI配置（比如providers里的注册）——最多两处改动。

情况2：依赖抽象（接口/抽象类）+ DI注册 #

这才是DI解耦的核心玩法！举个例子：

1. 先定义一个抽象契约：

abstract class IDataService {
  abstract fetchData(): Observable<any>;
}

2. 实现具体类：

class Dep implements IDataService {
  fetchData() { /* 具体实现 */ }
}

3. 在Angular的DI容器里注册：

providers: [{ provide: IDataService, useClass: Dep }]

4. 组件里依赖抽象：

constructor(private dataService: IDataService) {}

这时候如果要把Dep换成NewDep，你只需要修改DI注册的地方：

providers: [{ provide: IDataService, useClass: NewDep }]

组件的构造函数完全不用改！因为组件依赖的是IDataService这个抽象契约，而不是具体的Dep类——这才是DI真正的解耦能力：组件只关心“依赖能做什么”，不关心“依赖具体是谁”。

另外，你还可以用InjectionToken来进一步解耦，比如依赖是一个配置对象或者第三方库的实例，这时候组件依赖的是token，和具体实现完全无关，替换起来更灵活。

总结一下：DI的解耦不是让你不用改任何代码，而是把耦合点从业务代码的各个角落集中到DI配置层，同时通过抽象契约让组件和具体实现彻底脱钩，这才是它的价值所在。

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