构造函数之间的主要差异，ngOnInit就是ngOnInit为生命周期挂钩，并构造后运行。组件插值模板和输入初始值在构造函数中不可用，但在中可用ngOnInit。
实际的区别在于如何ngOnInit影响代码的结构。大多数初始化代码都可以移至ngOnInit- 只要不创建竞争条件即可。
构造函数反模式
大量的初始化代码使构造方法难以扩展，读取和测试。
将初始化逻辑与类构造函数分离的通常方法是将其移至另一个方法，例如init：
class Some {
constructor() {
this.init();
}
init() {...}
}
ngOnInit 可以在组件和指令中达到此目的：
constructor(
public foo: Foo,
/* verbose list of dependencies */
) {
// time-sensitive initialization code
this.bar = foo.getBar();
}
ngOnInit() {
// rest of initialization code
}
依赖注入
Angular中类构造函数的主要作用是依赖注入。构造函数还用于TypeScript中的DI注释。几乎所有依赖项都作为属性分配给类实例。
平均组件/指令构造函数已经足够大，因为由于依赖关系，它可能具有多行签名，因此将不必要的初始化逻辑放入构造函数主体中会构成反模式。
异步初始化
异步初始化构造函数通常被认为是反模式，并且有气味，因为类实例化在异步例程执行之前完成，这会创建竞争条件。如果不是这种情况，那么ngOnInit其他生命周期挂钩将是更好的选择，尤其是因为它们可以从async语法中受益：
constructor(
public foo: Foo,
public errorHandler: ErrorHandler
) {}
async ngOnInit() {
try {
await this.foo.getBar();
await this.foo.getBazThatDependsOnBar();
} catch (err) {
this.errorHandler.handleError(err);
}
}
如果存在竞争条件（包括在初始化错误时不应出现组件的竞争条件），则应在组件实例化之前进行异步初始化例程，并将其移至父组件，路由器防护等。
单元测试
ngOnInit比构造器更灵活，并为单元测试提供了一些好处，该答案中对此有详细解释。
考虑到ngOnInit在单元测试中不会在组件编译时自动调用该方法，因此ngOnInit可以在组件实例化之后对被调用的方法进行间谍或模拟。
在特殊情况下，ngOnInit可以完全存根以提供其他组件单元的隔离（例如，某些模板逻辑）。
遗产
子类只能扩充构造函数，而不能代替它们。
由于this之前无法引用super()，因此对初始化优先级设置了限制。
考虑到Angular组件或指令用于ngOnInit对时间不敏感的初始化逻辑，子类可以选择是否super.ngOnInit()调用以及何时调用：
ngOnInit() {
this.someMethod();
super.ngOnInit();
}
仅使用构造函数无法实现。
