Angular严格模式（strictPropertyInitialization）下组件成员初始化位置的选择方案

嘿，这个问题在Angular严格模式下挺常见的，咱们来逐个拆解你的三个方案，再说说最适合的选择：

方案1：属性直接初始化 #

export class NavComponent implements OnInit { 
  public userInfo$: Observable<LoggedInUser> = this.sessionService.getUserInformation(); 
  constructor(private sessionService: SessionService) {} 
  ngOnInit(): void {} 
}

这是最推荐的方案，完全符合Angular的最佳实践：

• 代码简洁直观，没有多余的语法
• 遵循了“构造函数仅用于依赖注入”的原则，不会把业务初始化逻辑塞进构造函数
• 因为userInfo$是Observable，它本身是惰性的，不会立即触发请求——只有当你在模板里用async管道订阅时才会执行，完全适配组件的生命周期
• 不需要使用确定赋值断言（!），避免了潜在的运行时风险

方案2：构造函数内初始化 #

export class NavComponent implements OnInit { 
  public isMobileMenuCollapsed = true; 
  public userInfo$: Observable<LoggedInUser>; 
  constructor(private sessionService: SessionService) { 
    this.userInfo$ = this.sessionService.getUserInformation(); 
  } 
  ngOnInit(): void {} 
}

功能上完全可行，但不推荐：

• Angular设计构造函数的核心目的是注入依赖，而非处理组件初始化逻辑。如果后续你的初始化逻辑变得复杂（比如需要判断条件、处理其他依赖），把这些放在构造函数里会让代码臃肿，也不利于单元测试
• 虽然严格模式下不会报错，但违背了Angular的生命周期设计理念

方案3：ngOnInit内用确定赋值断言 #

export class NavComponent implements OnInit { 
  public isMobileMenuCollapsed = true; 
  public userInfo$!: Observable<LoggedInUser>; 
  constructor(private sessionService: SessionService) { } 
  ngOnInit(): void { 
    this.userInfo$ = this.sessionService.getUserInformation(); 
  } 
}

这个方案的问题最大：

• 使用!确定赋值断言相当于绕开了TypeScript的严格类型检查，如果你后续不小心修改代码，忘了在ngOnInit里赋值，就会导致运行时的undefined错误
• 你的场景不需要等到ngOnInit才初始化——ngOnInit更适合处理依赖组件输入（@Input）的初始化逻辑，而调用服务获取用户信息不需要依赖输入属性，提前赋值完全没问题

总结 #

优先选择方案1。如果未来你的初始化逻辑需要依赖@Input属性或者其他组件生命周期相关的条件，再考虑把逻辑移到ngOnInit里（这时也尽量避免用确定赋值断言，可以考虑给属性设置默认值，比如userInfo$: Observable<LoggedInUser> = of(null)，再在ngOnInit里替换）。

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