这个功能请求现在已经成为我们的待办事项候选！在接下来的阶段，社区有60天的时间进行投票。如果请求获得超过20票的赞成，我们将把它移到我们的考虑列表中。
你可以在我们的文档中找到更多关于功能请求流程的详细信息。

我认为在这里Observable和AsyncIterator之间的比较是有误导性的。NgFor需要一个同步数组进行渲染，即使该数组是异步生成的。也就是说，在调用*ngFor="let item of items$ | async"时，items$必须是一个Observable类型的可迭代对象，例如一个Item[]数组。如果NgFor本身不是可迭代的，那么就不可能使用async管道来遍历Observable<Item>。

Angular可能支持使用AsyncIterable与async管道而不是Observable,但NgFor始终需要一个同步的可迭代值。

我将把这个问题的标题改为“在AsyncPipe中支持AsyncIterable”，我认为这是这里真正的功能请求。

请注意，我们已经开始了针对您的功能请求的社区投票过程。距离投票过程结束还有20天。
有关Angular功能请求流程的更多详细信息，请参阅我们的文档。

感谢您提交您的功能请求！看起来在投票过程中，它没有收集到足够的票数进入下一阶段。
我们希望保持Angular丰富且符合人体工程学，同时关注其范围和学习过程。如果您认为您的请求可能超出了Angular的范围，我们鼓励您与community合作，将其发布为开源项目package。
您可以在我们的文档中找到有关功能请求过程的更多详细信息。

我认为在这里Observable和AsyncIterator之间的比较是有误导性的。我认为很多人认为这是有误导性的。这个问题从一开始就问到了AsyncIterable,而不是AsyncIterator。

老实说，我不明白为什么会出现任何复杂性。对于已经支持Observable的任何事物，添加对AsyncIterable的支持应该是轻而易举的。

在我的项目中，我到处都在使用iter-ops,因为我想要最好的性能，而且我不想在除了Angular视图内部之外的任何地方使用像Observable这样的合成原始类型，因为它们并不自然地支持可迭代。在这个时代，我觉得这相当奇怪，公平地说。

以下是一个非常简化的例子，展示了我不得不采用的解决方法：
下面的组件每秒更新一次数字列表：

import {Component, OnInit} from '@angular/core';
import {pipeAsync, delay} from 'iter-ops';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent implements OnInit {

  source: AsyncIterable<number>;

  public data: number[] = [];

  constructor() {
    this.source = pipeAsync([1, 2, 3, 4, 5], delay(1000));
  }

  async ngOnInit() {
    for await(const i of this.source) {
      this.data.push(i);
    }
  }
}

然后是消费它的视图：

<div *ngFor="let item of data">
  <h1>{{item}}</h1>
</div>

所以我不得不为视图数据保留一个额外的变量，并遍历源数据来更新视图数据。
如果我们在Angular中支持 AsyncIterable ,我可以直接在视图中使用 source | async 。