为何组件内调用detectChanges()无法更新值，而setTimeout()却可行？

我来帮你拆解这个问题的核心原因，以及更优雅的解决方案：

为什么直接调用setFirstItemActive()无效？ #

当foundItemsList.changes触发时，虽然你的数据已经更新，但Angular的变更检测和Material Autocomplete内部的DOM渲染、_keyManager的选项同步还没完成。这时候_keyManager内部维护的选项列表还是旧的（甚至是空的），调用setFirstItemActive()自然找不到可激活的选项，所以看起来像是“没执行”——其实是执行了，但没有可操作的目标。

为什么setTimeout(() => {}, 0)能生效？ #

setTimeout会把你的回调函数放到宏任务队列里，等当前所有同步代码执行完毕、Angular的变更检测完成、DOM完全渲染好之后，才会执行这个回调。这时候Autocomplete的_keyManager已经同步了最新的选项列表，调用setFirstItemActive()就能正确激活第一个选项了。

为什么detectChanges()没用？ #

你说得没错，cdr.detectChanges()会触发当前组件及其子组件的变更检测，但它只是同步更新视图数据，并不会等待DOM渲染完成，也不会等待Material组件内部的状态（比如_keyManager的选项列表）更新。所以即使你调用了它，_keyManager的选项还是没准备好，自然没用。

更优雅的解决方案（避免用setTimeout和私有属性） #

首先，直接访问_keyManager这种私有属性是有风险的——Material的内部实现可能在版本更新时变化，导致代码失效。推荐用以下两种方式：

1. 用微任务代替宏任务（比setTimeout更及时） #

用Promise.resolve()把执行逻辑放到微任务队列，它会在当前变更检测完成后、DOM渲染完成前执行，足够让_keyManager同步好选项：

this.foundItemsList.changes.subscribe(options => {
  Promise.resolve().then(() => {
    const autoComplete = this.matAutocomplete.first;
    if (autoComplete._keyManager?.items.length > 0) {
      autoComplete._keyManager.setFirstItemActive();
    }
  });
});

2. 使用官方公开API（推荐） #

Autocomplete提供了activeOption属性，你可以直接设置它来激活第一个选项，不用依赖私有属性：

this.foundItemsList.changes.subscribe(options => {
  if (options.length > 0) {
    // 用微任务等待视图同步
    Promise.resolve().then(() => {
      this.matAutocomplete.first.activeOption = options.first;
    });
  }
});

3. Angular 16+：用afterNextRender #

如果你的项目用的是Angular 16及以上版本，可以用afterNextRender钩子，它专门用来等待视图渲染完成后执行逻辑：

import { afterNextRender } from '@angular/core';

// 在组件构造函数或ngOnInit里
afterNextRender(() => {
  if (this.foundItemsList.length > 0) {
    this.matAutocomplete.first.activeOption = this.foundItemsList.first;
  }
});

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