Angular 14中含构造函数依赖的抽象基类是否需@Injectable()装饰器？

结论先行 #

带构造函数依赖的抽象基类建议添加@Injectable()装饰器，哪怕当前去掉它应用仍能正常运行。下面具体解释原因：

为什么现在去掉也能运行？ #

当你的子类（比如ConcreteClass）添加了@Injectable()并在Angular的依赖注入系统中注册时，Angular会解析子类的构造函数——包括它继承自基类的构造函数逻辑。如果子类没有重写构造函数，或者重写后正确调用了super()传递依赖，Angular会自动处理整个继承链的依赖注入，因此基类没有@Injectable()也能暂时正常工作。

为什么必须加@Injectable()？ #

1. 明确代码意图
   给抽象基类标记@Injectable()，能直接告诉其他开发者：这个类是为Angular依赖注入设计的，不是普通的业务类，避免后续维护时的误解。

2. 避免潜在的注入错误
   如果基类的构造函数参数带有Angular的注入装饰器（比如@Optional()、@Self()、@SkipSelf()），没有@Injectable()的话，Angular无法识别这些装饰器，会导致依赖注入失败。另外，未来Angular版本更新时，DI机制的细节可能变化，没有@Injectable()的基类可能突然出现兼容性问题。

3. 支持抽象类的直接注入场景
   如果你未来需要直接将抽象类作为DI令牌（比如在模块或组件的providers中配置{ provide: AbstractBaseService, useClass: ConcreteClass }），此时抽象基类必须带有@Injectable()，否则Angular会报错——因为它无法将未标记的抽象类识别为可注入的令牌。

4. 符合Angular最佳实践
   Angular官方文档明确指出：任何需要依赖注入的类（包括抽象基类）都应该添加@Injectable()装饰器，哪怕它不会被直接实例化。这能保证DI系统的一致性，减少团队协作中的认知成本。

示例对比 #

错误场景（基类无@Injectable()）

// 基类：无@Injectable()，构造函数带@Optional()装饰器
export abstract class AbstractBaseService {
  constructor(@Optional() private logger: LoggerService) {}
}

@Injectable({ providedIn: 'root' })
export class ConcreteService extends AbstractBaseService {}

此时Angular无法识别@Optional()，会尝试强制注入LoggerService，如果该服务未提供则报错。

正确场景（基类加@Injectable()）

@Injectable()
export abstract class AbstractBaseService {
  constructor(@Optional() private logger: LoggerService) {}
}

@Injectable({ providedIn: 'root' })
export class ConcreteService extends AbstractBaseService {}

Angular能正确解析@Optional()，即使LoggerService未提供也不会报错。

内容的提问来源于stack exchange，提问作者Hari Krishnan U