Angular服务与组件属性实例化方式差异及基类适配疑问

让我把这四种写法的差异、你遇到的基类问题，还有单例、性能这些疑问一次性掰透：

1. 类属性直接 new 初始化 #

@Injectable() 
export class Service2 { 
  _svc = new Service1(); 
}

• 本质：完全绕开Angular的依赖注入（DI）系统，手动创建Service1实例。
• 单例性：不管Service1是不是在模块里注册成单例，每次创建Service2的实例，都会生成一个全新的Service1，和DI容器里的实例毫无关系。
• 适用场景：仅适合那些没有依赖（比如纯工具类、只有纯函数的服务）的对象——你说它能处理仅含函数的服务，就是这个原因。但遇到HttpClient这种Angular内置服务时，手动new必然失败：因为HttpClient依赖一堆底层对象（比如HttpHandler、模块配置），这些都得靠DI系统提供，你手动根本没法凑齐这些依赖。

2. 构造函数参数+访问修饰符（推荐写法） #

constructor(private _svc: Service1)

• 本质：Angular DI的标准用法，用语法糖简化了依赖注入+属性赋值的过程。Angular会自动从DI容器里查找Service1的实例，注入后直接帮你把它赋值给类的_svc属性。
• 单例性：完全遵循DI容器的规则——如果Service1是providedIn: 'root'或模块级注册，整个应用只会有一个单例，所有注入的地方复用同一个实例；如果是组件级注册，每个组件实例对应一个Service1实例。
• 适用场景：所有场景！不管是普通服务、基类服务还是需要依赖HttpClient的API服务，这种写法都能完美处理，也是Angular官方最推荐的方式——你平时用这种是完全正确的。

3. 构造函数内手动 new #

constructor(){ 
  _svc = new Service1(); 
}

• 本质：和第一种写法核心一致，都是绕开DI手动创建实例，只是初始化时机从类属性初始化阶段移到了构造函数执行时。
• 注意坑点：代码里如果没写this._svc，会不小心创建全局变量而不是类属性，这是很容易踩的bug。
• 单例性&适用场景：和第一种完全一样——只能处理无依赖的简单服务，无法初始化HttpClient这类需要DI的对象，每次创建Service2都会生成新的Service1实例。你说它适用于部分静态类，也是因为那些静态类不需要依赖注入的对象。

4. 构造函数参数手动赋值 #

constructor(_svc1: Service1){ 
  _svc = _svc1; 
}

• 本质：这是DI的“手动写法”，没有用访问修饰符的语法糖，所以需要自己把DI注入的_svc1赋值给类属性（同样要注意加this.，不然会变全局变量）。
• 单例性&适用场景：和第二种写法完全一致——复用DI容器的单例，能处理所有依赖场景。只是比第二种多了手动赋值的步骤，没必要多写，所以一般优先用第二种语法糖。

你关心的几个关键问题解答 #

1. 什么时候复用单例？什么时候创建新实例？ #

• 复用单例：只有用第二种、第四种（正确赋值的情况下）DI注入的方式，才会复用DI容器里的实例。单例的范围由Service1的注册方式决定（根级/模块级/组件级）。
• 创建新实例：第一种、第三种用new的方式，每次都会生成全新的Service1实例，和DI容器无关。

2. 基类中无法实例化Http的解决方案 #

HttpClient必须由DI系统注入，手动new绝对行不通。正确的做法是在基类的构造函数里通过DI获取HttpClient，子类调用super()时传递这个实例：

// 基类API服务
@Injectable()
export class BaseApiService {
  constructor(protected http: HttpClient) {}

  // 封装通用的GET方法
  protected get<T>(url: string): Observable<T> {
    return this.http.get<T>(url);
  }
}

// 子类用户API服务
@Injectable()
export class UserApiService extends BaseApiService {
  constructor(http: HttpClient) {
    super(http); // 把DI注入的http传给基类
  }

  getUser(id: number): Observable<User> {
    return this.get<User>(`/api/users/${id}`);
  }
}

这样基类就能正常使用HttpClient了，因为所有依赖都由DI系统初始化完毕。

3. 性能差异 #

• DI注入方式（2、4）：性能几乎无额外开销——DI容器在应用启动时就初始化好单例，后续注入只是获取引用，速度极快。
• 手动new方式（1、3）：如果频繁创建实例，会增加内存开销；如果Service1是重服务（比如初始化了大量资源），重复创建会浪费性能，还可能导致状态不一致。

总结推荐 #

• 优先用第二种写法（构造函数参数+访问修饰符），简洁、规范、能处理所有场景，完全符合Angular的设计理念。
• 除非你明确需要多个独立的实例，且服务无任何DI依赖，否则绝对不要用new手动创建服务实例。

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